The GOTOOLCHAIN documentation has several references to PATH-related behavior that would be potentially reasonable/interesting for us to do something meaningful with:

When GOTOOLCHAIN is set to <name> (for example, GOTOOLCHAIN=go1.21.0), the go command always runs that specific Go toolchain. If a binary with that name is found in the system PATH, the go command uses it.

To run a toolchain other than the bundled Go toolchain, the go command searches the process's executable path ($PATH on Unix and Plan 9, %PATH% on Windows) for a program with the given name (for example, go1.21.3) and runs that program.

For the path form, the go command scans the PATH for any executables named for valid toolchains and uses a list of all the toolchains it finds. Using that list of toolchains, the go command identifies up to three candidates:

• the latest release candidate of an unreleased Go language version (1.N₃rcR₃),
• the latest patch release of the most recently released Go language version (1.N₂.P₂), and
• the latest patch release of the previous Go language version (1.N₁.P₁).

These are the supported Go releases according to Go's release policy. Consistent with minimal version selection, the go command then conservatively uses the candidate with the minimum (oldest) version that satisfies the new requirement.

Part of me thinks we should put aliases (go1.X.Y + go1.X) in /usr/local/go/bin, but /usr/local/go is otherwise a completely pristine copy of upstream's original artifacts, so that feels slightly wrong and perhaps they belong in /usr/local/bin instead?

However, my main thought for the actual use case for these aliases is folks doing RUN --mount=... to mount several Go versions and use them explicitly with an appropriate GOTOOLCHAIN value (such as path) and $PATH, so perhaps the usability should override the pedantry?

It's also very possible I'm overthinking the whole thing and none of this matters and we should do nothing ("Enjoy Arby's"). 🤷