They do propose that, but with caveats. They mention removing string(i) in, say go 1.20. If a module notes that the maximum version of go that the module works with is 1.19 (because it uses that feature), then the 1.20 compiler can compile that module in go language 1.19 mode. Thus you can use 1.20 features in your module and still depend on the module that uses the deprecated syntax, because the go compiler can still operate on that old code.
This is different from python 3 because python 3 cannot run python 2 code, even if told that some library is python 2. That is where the migration pain came from.
I'm unconvinced by the max-version part, I can't see how it doesn't require either
A) being overly restrictive, and declaring the current released version as your max, breaking for a short time on each new lang version
B) being psychic, and knowing when (without the aid of semver) your package might break
An unmaintained package will not be updated with the max flag when the breakage occurs.
Any package always declaring the current version will have to be updated for every new release.
Both seem like a lot of admin.
I know using unmaintained packages isn't ideal in the first place, but it happens, and packages exist that are pretty much "finished" and very light on bugs, if they were stable and heavily exercised for some time before losing their maintainers.
An unmaintained package doesn't need new features from then-future versions of Go, so it's fine if you declare the current version as your max. It doesn't break in the new version, it just doesn't have access to features introduced after the max version.
As outlined in the proposal, you wouldn't miss out on performance improvements since it would still be the same underlying compiler and the version just controls the syntax rules. (And even if that were the case, it's not a very bad worst-case scenario for an abandoned project.)
The breakage you describe in A) shouldn't happen according to the proposal. The compiler for toolchain version X+1 should still be able to compile code that is language version X.
This is different from python 3 because python 3 cannot run python 2 code, even if told that some library is python 2. That is where the migration pain came from.