Speaking as the person Rob Pike handed the formal power to (8 years ago now), I don't think that change has much to do with it.
We've known about the problem for a long time. I have notes from the run up to Go 1 (circa 2011) where we considered making this change, but it didn't seem like a huge problem, and we were concerned about breaking old code, so on balance it didn't seem worth it.
Two things moved the needle on this particular change:
1. A few years ago David Chase took the time to make the change in the compiler and inventory what it broke in a large code base (Google's, but any code base would have worked for that purpose). Seeing that real-world data made it clear that the problem was more serious than we realized and needed to be addressed. That is, it made clear that the positive side of the balance was heavier than we thought it was back in 2011.
2. The design of Go modules added a go version line, which we can key the change off. That completely avoids breaking any old code. That zeroed out the negative side of the balance.
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.
We've known about the problem for a long time. I have notes from the run up to Go 1 (circa 2011) where we considered making this change, but it didn't seem like a huge problem, and we were concerned about breaking old code, so on balance it didn't seem worth it.
Two things moved the needle on this particular change:
1. A few years ago David Chase took the time to make the change in the compiler and inventory what it broke in a large code base (Google's, but any code base would have worked for that purpose). Seeing that real-world data made it clear that the problem was more serious than we realized and needed to be addressed. That is, it made clear that the positive side of the balance was heavier than we thought it was back in 2011.
2. The design of Go modules added a go version line, which we can key the change off. That completely avoids breaking any old code. That zeroed out the negative side of the balance.