Works fine for me in Poudriere. Please address the issues raised by @diizzy. LGTM conditional on that.

The port fails to build on 15-CURRENT outside of Poudriere:

I'm not a fan of USES=zig doing all the building in the stage step. Would it be possible to have the building be done in the build step and only stage in the stage step?

Looks good now, but perhaps someone with more experience with libxo should have a look over D50699 and this one.

Please adjust the indentation as per style(9).

Please adjust the indentation style as per style(9).

This is the same idea as OpenBSD's O_BELOW resp. F_BELOW. Perhaps the API can be designed to match OpenBSD's?

But the easiest way to prevent that is simply to ensure that we keep providing the latest go release. As long as the minor doesn't exceed what's in the ports tree, that toolchain-downloading behaviour will never trigger.

You're missing the point, I suspect. Go no longer has that problem. Go will no longer try to build go121 programs with a go124 stdlib. It will build go121 with a feature set identical go121, and this happens transparently and automatically. Go designed it this way so that there is never a need for multiple go versions. Technically we could leave go122 in the ports tree and it'd build all future Go programs.