If I understand #33097 correctly, on Windows the resolver still defaults to those C library functions, but can be overridden to a pure-Go implementation by setting GODEBUG=netdns=go or Resolver.PreferGo.
The first is that the final sentence in the comment suggests that we have failed to document the behavior of Go 1.19 and later on Windows. We should perhaps somehow indicate that the rest of the comment applies.
The second is a point that the comment currently doesn't mention at all. When cgo is not supported (because CGO_ENABLED is set to 0, which happens by default if there is no C compiler when the Go distribution is built), then on most systems only GODEBUG=netdns=go is available. However, on Windows and Darwin GODEBUG=netdns=cgo works even if cgo is not supported.
Any changes here need to be both precise and terse. We do not want several sentences discussing these unusual situations.
I think part of the problem is that the second paragraph begins with “On Unix systems,” and the third paragraph seems to only clarify what came before it. So the third paragraph reads as though it applies only to Unix.
But, it seems to me that that paragraph still doesn't apply to Windows. The build constraint in netgo.go excludes darwin and windows, the logic in net.initConfVal sets netCgo by default on windows and plan9, and (*net.conf).hostLookupOrder also has special cases for android, windows, and plan9.
From what I understand from reading the code, the behavior seems to be:
On all platforms, there are two resolver implementations: one in pure Go, and one using the platform's native API (typically a C library).
On Unix systems other than macOS, the behavior is as described in the long paragraph today. (“By default the pure Go resolver is used,” but “the cgo-based resolver is used instead under a variety of conditions”.)
On macOS, Windows, and Plan 9, the platform's resolver is used by default. (The pure Go resolver is used only if it is explicitly enabled.)
On these platforms, the platform's resolver does not actually require the use of cgo or CGO_ENABLED, although it may call into a C library.
It is not clear to me why the code to choose the resolver uses a different approach on macOS (setting forceCgoLookupHost) than the other two (setting confVal.netCgo).