Microsoft puts more effort into keeping things working than Apple does. Go works on XP as a result of the work Microsoft has done, not the Go project. Apple change subtle things in each OS X release making it onerous to support the older ones.

This is not true, Go "keeps working" on Windows because on Windows Go is ABI compliant and uses stable interfaces. In particular, on Windows Go interacts with the system through kernel32.dll and uses the standard Windows ABI.

Same is true for Solaris, where Go interacts with the system only through libc.so.1, and uses the System V ABI for the calling convention and thread-local storage.

On Linux the system call interface is stable (unlike Windows and Solaris), so on Linux Go "keeps working" too (albeit I will note that we don't use an ABI-compliant method for determining the current time...).

Darwin is just like Windows and Solaris, and unlike Linux. The system call interface is not stable, but unlike Windows and Solaris we use it anyway, and the method we use for thread-local storage is unportable and system-dependent. However, Darwin still has a stable interface through its own libc, and there's an ABI-compatible method to do thread-local storage as well. If Go would use the standard system interfaces on Darwin (like it does on Windows and Solaris), Go would just "keep working" on Darwin too and would not require changes each time a new macOS release is made.

It is true that Microsoft is very committed to forward and backwards compatibility, but only for its stable and documented interfaces (which Go uses), undocumented interfaces break all the time; Darwin's forward and backwards compatibility guarantees might not be as strong as Microsoft's over large periods of time, but they are still pretty good as long as you use the supported interfaces.

Right, it's a weak argument. Apple tends to pull the plug rather quickly, as well, but that's tangential.