Attached are proposed patches for default (3.5), 3.4, and 2.7 branches.  (The patch for 3.4 is identical to that for 3.5 so there are only two files in total being attached.)

Regarding the exception being raised:
* An ImportError is now consistently being raised across Python versions.  This is believed to be a more consistent behavior than using NotImplementedError but it is debatable whether all such situations might be switched to instead use NotImplementedError in the future.
* Implementation is done via a try-except around the problematic attempt to use _multiprocessing.SemLock inside the multiprocessing.queue module; it is believed this change has minimal risk.
* The text of the ImportError message differs only slightly from that used in the exception highlighted in issue 3770.  In 2.7, the code raising this exception is encountered in both code execution paths (as described in issue 3770 and as described here) but in 3.x various changes have broken this shared execution path.  After staring at it for quite some time, I believe a less-than-simple refactoring is required to get both execution paths to encounter the same exception -- I'm punting on that for now.  Ultimately, I believe the goal was not to leave the error message inspired by issue 3770 but instead to clean it up and eliminate it as part of further code improvement efforts.  I believe doing so is well beyond the scope of this issue but is still something that deserves addressing.

Regarding the documentation of the exception:
* A note has been added to the "Reference" section's "Pipes and Queues" subsection, describing the potential for and reasons behind an ImportError being encountered.
* The note that previously appeared in the "Introduction" section's "Synchronization between processes" subsection (introduced per issue 3770) has been relocated to similarly appear in the "Reference" section's "Synchronization primitives" subsection.  Such a note appearing in an introduction section serves as a distraction to the reader who is hopefully learning about key concepts; it is better located in the formal documentation around the synchronization primitives where caveats and details should be conveyed.  Making this change (relocation) keeps the two explanations of the ImportError arising from different places in the code better in parallel / symmetry with one another.

Running through the complete battery of tests on Debian Hurd was not possible as the sequence of tests could never complete (on the default/3.5 branch at least) -- various tests were observed to hang and never complete.  While Debian Hurd may not be a mainstream supported platform for Python, given its lack of important functionality such as a working sem_open implementation, it is still rather interesting as a testing platform to see how things behave when the underlying system is unable to provide numerous chunks of key functionality to Python.