We on the Go team team also muse about a Go 2.x occasionally (no concrete plans), but the number one rule would be not pulling a Python 3 or Perl 6 and fracturing the community in two.
Maybe you guys could do like Java did and eventually drop the 1.x from the naming, leaving just the x, or do you see any issue with the perception of backwards compatibility?
I think that languages like Go are objectively speaking in much better position to release 2.0 or 3.0 updates because we have the example of Python 3 and have some pointers what not to do.
I think even major (=with source-level breaking changes) version bumps are feasible specifically with compiled languages. This is because you can still continue to support the both versions of the language in the compiler, and if you are careful with semantic changes, you can support linking packages of two different versions together.
Additionally, if you start designing breaking changes from the start with the mentality that an automatic tool should be able to upgrade the code base, that eases up the migration a lot. (There is 2to3 with Python, but that didn't always work, which to me means that the language changes weren't exiplicitly designed to be automatically upgradable.)
Btw. I wrote this thinking that a major version bump means source-level incompatibilities – but it's possible, although challenging, to introduce major new features even without.
In addition, a static typed language allows you to find most breaking changes at compile time. The bytes/str situation would easy to fix in golang, instead of exploding at runtime now and then as in Python3.
Go 2.x is not much more than a collection of thoughts, improvements, and opportunities that could come about with breaking backwards compatibility. No real work, to my knowledge, is even planned for it.
I haven't seen anything about it, which I absolutely love (based on fear of a Python 3 situation).