TLDR: if there aren’t breaking changes it won’t be called 2.0 it will be called 1.12 or something like that.
Go is currently planning their 2.0 release precisely so that they can make breaking changes. It was a big deal when they reached 1.0 for exactly the reason that they stopped making breaking changes. Ditto with Rust. We are following the exact same course. If it feels different, that’s because you weren’t using either language pre-1.0.
See also the Python 2 vs 3 transition and Ruby 1.x => 2. Comparing with Perl5 is ignoring the huge changes made in Perl2, Perl3, Perl4 and Perl5, not to mention Perl6.
That leaves Java and C++. Yes pre-1.0 Julia was more breaking than those two, ancient, industrial warhorses.
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  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" .