With https://go.dev/doc/toolchain as the authoritative documentation on toolchain semantics, all interpretation errors are thus to blame on me.

The toolchain mechanism has been introduced as of Go 1.21(.0). Gomega follows the N, N-1 support policy which at this moment resolves to 1.23.x and 1.22.x. It's debatable whether the toolchain should be 1.22.10, 1.22.0, or maybe 1.21.0 to better allow for some skew. But to my limited understanding we cannot keep a toolchain definition from Gomega's go.mod anymore, more so as our dependencies also now introduce toolchain definitions of their own.

You can always enforce your local toolchain with GOTOOLCHAIN=local, but if it is outside the lower limit of the support range this will fail. Still, you have some control, in particular, the choice of 1.22.x or 1.23.x if I understand the situation correctly.

With https://go.dev/doc/toolchain as the authoritative documentation on toolchain semantics, all interpretation errors are thus to blame on me.

The toolchain mechanism has been introduced as of Go 1.21(.0). Gomega follows the N, N-1 support policy which at this moment resolves to 1.23.x and 1.22.x. It's debatable whether the toolchain should be 1.22.10, 1.22.0, or maybe 1.21.0 to better allow for some skew. But to my limited understanding we cannot keep a toolchain definition from Gomega's go.mod anymore, more so as our dependencies also now introduce toolchain definitions of their own.

You can always enforce your local toolchain with GOTOOLCHAIN=local, but if it is outside the lower limit of the support range this will fail. Still, you have some control, in particular, the choice of 1.22.x or 1.23.x if I understand the situation correctly.

Thanks, I'm aware of the background to toolchain and how to avoid some issues; but nonetheless it's not needed here and only showed up when it caused a regression in an internal system.

I think the correct and safe thing to do it remove it.

Thanks!