Good stuff but incomplete I think.
First, I forgot to mention that I am not even new to Go as I am looking at it to see if I can use it; I never use it so far… but people are telling good thing about it so I am checking it!!
Concentrating on binary distribution (in container) and therefore cross-compiling it is clear that referencing the correct kernel sources (actually, just headers) is a must. In C, or C++, the kernel source is part of the cross-tool chain build “sandbox”; you do not rely on the local host sources for obvious reasons. I do not see that in Go’s cross-compile documentation on golang.org. I do not see the kernel source in the git repo of the go compiler either (may be I miss it). Given the fact that the cross-compiler targets a wide variety of OS (Linux, Windows, etc.) there must be something somewhere but I fail to see it. (Windows is probably even worst than Linux when it comes to kernel version, but this is just a guess). So, the question for option 2 is how to “switch” the kernel source? On Linux build machine, how to “switch” to the correct Mac OS kernel that you want to target? Or vice-versa.
Of course option 3 is possible, unless you target a small environment like a raspberry Pi with a real application (not just a toy). But this option does not integrate well into a high quality CI infrastructure; cross-compilation is much better in such context.
Ultimately, the doc on golang.org is incomplete. It needs to be augmented.
On the GO binary and package aspect; you are right, normally the kernel is totally abstracted. In C/C++ this is achieved by the fact that the local libc.so is used at the run location. But since Go is a static executable it must cater for the abstraction that libc provides. Hence, compiling the cross-compiler to the correct target kernel version is important. The worst thing that can happen is to use a compiler built on a recent kernel and execute the application binary it generates on an old kernel; depending on what you are doing you application may simply burn and crash. The normal way to build and distribute binaryies is to target the oldest kernel that supports what you need. May be I am wrong and Go application are compiled to use libc but this is not what I read.
No, I am not targeting kernel development using GO. That would be a bad idea IMHO.