I can see the appeal, but hope they keep it opt-in so that people can choose their preferred workflow without surprises.
In corporate environment, it might trigger some unexpected alarms (or be blocked)
Gentoo got this right: by default, the "old" behaviour should be kept (no automatic update) and it should only be opt-in
The automatic updating toolchain is not a bad idea, and in most cases it works great. Once in a while though, there's a fuck up and breaks your build or something changes that you didnt expect.
The best way forward is to keep the old tool in a backup location, and have the user be able to revert the update with a single command. Then the user is able to safely return to the old one when the inevitable breakage happens. You could even opt-in to analytics for this action, and the owner of the tool would know if a particular update is a screwup (aka, many people reverted it).
I think you misundertood how this feature works.
If you have a `go.mod` that sets a `go` directive with a version bigger than the version your Go toolchain is currently running, it will download the binary automatically and pass the commands to the new binary. However this doesn't replace your `go` binary in say, PATH, the new toolchain will be downloaded at `GOPATH`, the same as it does with your modules. This is why there is nothing to backup here, nothing is deleted.
Also, keep in mind that if Go is downloading a new toolchain, it means your project will not work with the current toolchain: because if you set `go 1.23` in your `go.mod`, and your current `go` is version 1.22, it would fail regardless until you either fix your `go.mod` or upgrade your `go` toolchain. What Go is doing here is the later, automatically for you.