But the root cause of that broken behavior is not the Go resolver, it's broken configuration in resolv.conf

You are assuming all possible configurations could somehow be represented in resolv.conf. They can't.

For example, the MacOS resolver can be configured to send queries for a particular domain to an alternative server. This situation is frequently encountered by VPN users. How would you represent that in /etc/resolv.conf?

dighost

The problem with the pure go resolver is it assumes making DNS queries and resolving hostnames are the same thing. This isn't really true:

.local

The pure Go resolver captures some but not all of this behavior. This results in the pure Go resolver being some amount of "broken" not just on MacOS, but on Linux as well. Go's own documentation admits the many limitations of the pure Go resolver:

By default the pure Go resolver is used, because a blocked DNS request consumes only a goroutine, while a blocked C call consumes an operating system thread. When cgo is available, the cgo-based resolver is used instead under a variety of conditions: on systems that do not let programs make direct DNS requests (OS X), when the LOCALDOMAIN environment variable is present (even if empty), when the RES_OPTIONS or HOSTALIASES environment variable is non-empty, when the ASR_CONFIG environment variable is non-empty (OpenBSD only), when /etc/resolv.conf or /etc/nsswitch.conf specify the use of features that the Go resolver does not implement, and when the name being looked up ends in .local or is an mDNS name.

The reason this brokenness tends to be noticed on MacOS more than Linux because most binary releases of popular Go programs (kubectl and terraform are two I've used personally) are cross-compiled, which in practice involves disabling cgo. So, the fallback to the cgo resolver can't happen. Native-compiled Go programs on MacOS resolve fine because they use the cgo resolver unconditionally. A Linux go binary with cgo disabled is also broken, but disabling cgo on Linux isn't nearly as common.

If this decision to unconditionally use the cgo resolver were changed, then Go would need to do a better job detecting situations where it would not behave as desired and falling back, as it does on Linux. As explained in the documentation quoted above, there are many things that might trigger these fallbacks, but many of these are lacking their MacOS counterparts. For example, MacOS doesn't have a /etc/nsswitch.conf. I believe the equivalent configuration is in the System Configuration Database, which isn't mentioned at all among the checks that might trigger a fallback to the cgo resolver.

In other words, no longer unconditionally using the cgo resolver on Darwin would subject all Go users, not just those using cross-compiled binaries, to the brokenness already widely reported here and in mentioned other issues.