Comment 1:

Try submitting a CL.
http://golang.org/doc/contribute.html

Comment 2:

Labels changed: added packagechange.

Status changed to HelpWanted.

Comment 3:

Labels changed: added priority-low, removed priority-medium.

Comment 4:

Hello, please take a look at http://golang.org/cl/5246052/

Comment 5:

Labels changed: added priority-someday.

Comment 7:

In related news, it seems you can't really use Unshare once goroutines have been started.
iant:
"""
The unshare system call effectively undoes parts of the clone system call.  The clone
system call is used to create new threads.  So I would expect the unshare system call to
only affect the calling thread.  I would not expect it to affect all threads in a
process.  That seems to more or less match the high level description in
http://www.kernel.org/doc/Documentation/unshare.txt , although I agree that matters are
not entirely clear.
Since goroutines are free to move between threads (unless you call
runtime.LockOSThread), and since the Go runtime creates new threads as needed, I don't
think there is any reliable way to use syscall.Unshare in a Go program.
"""

Comment 8:

Labels changed: added repo-main.

Comment 9:

Adding Release=None to all Priority=Someday bugs.

Labels changed: added release-none.

Comment 10:

I'm not sure why this CL was never submitted.  It should be possible to use unshare for
the specific case of a child process running after fork, which is what the CL did.

CL https://golang.org/cl/23233 mentions this issue.