In golang/go#23172 (comment), @cespare writes:

It's unfortunate that the best reference for this convention is still this issue, since in the intervening four years no documentation change has been merged.

Additionally, I have found during this time that, in practice, I cannot use the purego tag for its intended purpose in our internal codebase at my company. The reason is that we use go-cmp. Some of go-cmp's core functionality is unsafe. That functionality is now behind a purego build tag. Enabling the purego tag makes most of our tests panic. We have packages with asm as well as pure-Go implementations, and we often want to run automated tests of both code paths, but we cannot run the tests with purego, so we end up using a different build tag to indicate "Go rather than assembly".

I'm not even sure what the right fix is. Maybe the ideal outcome would be that something in the Go standard library (testing? reflect?) would allow go-cmp to do what it needs to do without unsafe. But for now, the existence and popularity of go-cmp kind of "infects" the purego tag and makes it a not-very-useful convention.

I'm not sure what the right fix is, but perhaps an explicit gocmp_unsafe build tag that enables the use of unsafe even if purego is specified? There isn't an obvious fix here since we must use unsafe to introspect unexported fields.

\cc @neild