It is very common for language runtimes to link and depend on libc on Unix, even if the libc API is not directly exposed in those languages. Go is somewhat unusual in this regard.
MacOS doesn't guarantee backward compatibility for direct syscalls. This has caused bugs like this with compiled Go binaries:
Go has very recently started using libSystem (which is analogous to Linux libc or Windows CRT) on macOS to avoid this issue.
On a more philosophical level, POSIX is defined in terms of a C standard library, and not using libc means Go doesn't support and/or must implement itself various features that are otherwise provided to POSIX applications by the system (like locale handling). Your mileage may vary in terms of whether that's a bad thing or a good thing.
> It is very common for language runtimes to link and depend on libc on Unix
It is, and this is where you have to choose between a fragile executable that linked to a specific vendor and version of libc (glibc, musl, etc.). or a bloated executable that statically links it.
> MacOS doesn't guarantee backward compatibility for direct syscalls.
Sounds like Go should use the stable API MacOS does offer. If the stable API is libSystem (different than libc), then so be it.
But if we're talking about Linux libc, there's no reason for Go to use it.
> POSIX is defined in terms of a C standard library
Specifically POSIX.1 (not POSIX.2).
Also, for what it's worth, POSIX compatibility falls short of Go's goals for compatibility. Specifically, on Windows. So I'm not sure what there is really to gain by following a different language standard for a different set of platforms that you desire to support.
It's also worth considering that none of the major systems are actually POSIX-compliant today. You're always going to need to make specific allowances if your standard library supports anything beyond the absolutely trivial even if you ignore Windows.
On glibc-based Linux you generally need to compile on a system running the oldest (or close to) version of glibc you want to support. I suspect this was the singlehanded reason for Go being built that way.
That said, on macOS it makes a lot less sense because libSystem's compatibility guarantees work a lot like those of Win32, where you can safely compile on newer versions of the OS as long as you don't actually use features that are newer than your deployment target.
Why do you want to use libc for Go? You wouldn't use the Rust standard library for Go, why the C standard library?