When they write "bring along" they do not mean "Go 2 will be backwards compatible with Go 1". Pre-1.0, Go extensively used "go fix" to automatically upgrade older Go code to newer versions. (If they had never introduced incompatible changes as you seem to be claiming, this would not have been necessary.) They will most likely do the same thing for upgrading code from Go 1 to 2. Although that alone is likely to be insufficient as the failure of py2to3 demonstrates; they will probably need to also support using Go 2 packages from Go 1 or vice versa.
Julia has taken a similar albeit less automatic approach with deprecation warnings. When a breaking changes have been made, in one major release it continued to work but issued a warning telling you how to change your code. Only in the following major version did the code actually break. This allowed people to upgrade, run their tests (you have tests, right?), fix the warnings and be good to go.
More recently FemtoCleaner [1] has been introduced, which automatically makes PRs to projects and upgrades them just like "go fix" does. When we release Julia 2, we'll use a similar approach, so if your happy with how Go is doing things, you should be happy with how Julia does them.
It's fairly straightforward to avoid the Python 2/3 debacle, they key is to always allow packages to support two "adjacent" major versions at the same time, so as to not cause "upgrade deadlock" [2].
[1] https://github.com/JuliaComputing/FemtoCleaner.jl
[2] https://discourse.julialang.org/t/1-0-adoption-path/7922/39