What about let's say 5 years from now, someone digs up a Go project from 2022, decides to get it up to speed for 2028, updates the version line. Is there something that would remind them to check for breaking changes, including this one? Perhaps the go project initializer could add a comment above the version line with a URL with a list of such changes. Though, that wouldn't help for this change.
I think the key difference here is to consider toleration vs adoption. Old code is able to tolerate the changes and still work in new ecosystems. There is still work on maintainers if they want to actually adopt the features themselves. Allowing these two concepts to work together is what allows iteratively updating the world, rather than requiring big bang introduction of features.
As for validating your software, the answer is the same as its always been… tests, tests and more tests.
