Rational:

I am using go install to deploy code to a cluster since the go compiler compiles really fast and this save me from having to manage building and distributing binaries.
It would be nice if I could also take advantage of the small performance gain of newer instructions sets available with GOAMD64, v2 and above however my cluster is made of heterogeneous machines and CPUs which not all support the latest features making it impossible or sub optimal to hardcode a level in my deploy script.

Proposal:

Add GOAMD64=local level to the toolchain, the toolchain will at compile-time find what would be the highest compatible micro-architecture level of the compiling host's CPU and compile the binary as usual using the equivalent microarchitecture level.
Thus running GOAMD64=local go build . (or other building command) on a compiling host that supports at most GOAMD64=v2 will produce an identical result as running GOAMD64=v2 go build ., same for all architecture levels on CPU that would support at most thoses respectively.

If a command of the toolchain that might be GOAMD64 dependent for results is invoked with GOAMD64=local while the toolchain is built with runtime.GOARCH != "amd64" the invocation fails. (go install, go build ... but not things like go env or go help)

I am not proposing that GOAMD64=local become defaults, just that it exists, by default the toolchain will continue to emit GOAMD64=v1 for GOARCH=amd64 binaries (even for go install as spuriously changing the micro architecture level invalidates different level build caches which would make a go build . shortly followed by go install . much slower).