I'm on the Go team myself.
You are of course correct that Go has chosen to make system calls directly, in a way that Mac OS X explicitly does not support. But there is a difference between "not supported" and "not working." What I'm wondering about is when Go's approach causes actual problems, rather than theoretical ones. You cited specific problems in your original post above. Please file issues for the actual problems, so that we can fix them. Thanks.
I'll consider filing bug reports for them, although I feel that it's probably more of a job for a QA person being paid by Google to do the work, rather than my job, seeing as I am not currently with Google. At present, none of the projects where I had considered using Go have used Go because of these deficiencies, so I have no real incentive to do the legwork for free, if it's going to take me away from other work.
Here's a partial list of interfaces that are implemented in the Libc portion of Libsystem, rather than directly as system calls, and are therefore unavailable to call from Go:
bsd_signal, confstr, creat, crypt, encrypt, ftw, gethostid, gettimeofday, getwd, killpg, nftw, semctl, setpgrp, setregid, setreuid, shmctl, sigsetmask, sigblock, sigpause, sighold, sigrelse, sigignore, statvfs, tcgetsid, uname, utmpx
etc., including all 32 POSIX1e ACL related commands, almost all pty related code, much of termios.
Here's a partial list of system calls which use an additional parameter/error checking/descriptors at the user/kernel boundary, and therefore randomly exhibit POSIX non-compliant behaviour when called from Go programs:
posix_spawn, posix_spawnp, pthread_create, pthread_mutex_lock, pthread_mutex_unlock, fork, kill, sigaction, sigvec, etc. ...like I said, a job for a QA person to identify them all.
Ideally, what would happen, is that The Open Group VSU, VSX, VSTH, and VSRT tests, at a minimum, would be converted to Go, and verified that they get the same results as their C language counterparts when run against any UNIX or UNIX-like platform. Barring that (due to licensing expense), the Open Source LSB-FHS, LSB-VSX, and LSB-OS tests would be used instead.