IIUC this is only for static binaries?

BTW, have you looked into ko? Although it depends on Kube: https://github.com/google/go-containerregistry/tree/master/cmd/ko

IIUC this is only for static binaries?

We mostly use static binaries. But is that necessary?

I have not looked into ko before. I don't think anyone wants Kubernetes dependency for building OCI images.

For dynamic binaries you are likely to require a bunch of apt/dnf packages, and probably it is better to use Docker/BuildKit/img/Buildah/whatever?

Is the purpose here to build Go binaries that are runnable on certain container environments, or to build the container image too?

If you want the former, I presume that the already accepted #26492 will do the job.

If you want the latter, I'd imagine that the solution would pull in lots of code into the Go tree. Why not have that as a build/release tool that wraps go build instead?

The go command and the go project cannot serve every possible need. Instead we aim to provide a good foundation and good building blocks for custom tooling. It should be very easy to write a go-to-docker given the current go command functionality. And maybe -static in #26492 will make it even easier. A docker container can be and is often a lot more than one binary. It makes much more sense for additional tools layered on top of the go command to build those containers. If more from the go command is needed, great, let us know details. But broader packaging issues like generating docker containers directly is far beyond the go command's scope.