The go version line in go.mod doesn't peg the version of the actual compiler, it only pegs the version of the language. It's analogous to flags like --std=c++20

The go version line in go.mod doesn't peg the version of the actual compiler, it only pegs the version of the language. It's analogous to flags like --std=c++20 in C++ compilers. If you have code that is, for example, valid go 1.17 and also valid go 1.18, but it behaves differently somehow between the two for reasons that are considered implementation details instead of language changes (for instance, depending on behavior changes in standard libraries), the behavior you get will depend on the version of the go tool that you happen to be running when you build it, not by what's defined in go.mod. That's sort of what's changing in go 1.21 - there's now a "toolchain" directive to specify the precise compiler version that should be used, which is slightly independent of the version of the language semantics that you want to apply. But of course, it's still not that clear - because the toolchain directive is only respected in the "main" module, and it's also still only a minimum. That means you can't actually guarantee that your module will always be built with exactly that toolchain version - if it's included in someone else's module then it will be built with whatever they happen to be running, and it can always be built with a later version no matter what.