I'm not well informed about the breaking changes made under the hood in Python 3. But I wonder if breaking backwards compatibility in this case wasn't simple an externalization of costs. The community certainly went through a TON of work to port libraries, etc. Could all those man-hours have gone towards making incremental, backwards compatible changes instead?
I think the takeaway is that if you want to make breaking changes, make a new thing and turn the old thing over to a maintenance team. If after a while you learn some things that could improve the old thing see if they can be incorporated without breaking compatibility or if the new thing is really so much better people will switch.
Everything that I've heard that was changed from Python 2 to 3 are reminiscent of things that Perl5 handled while maintaining backwards compatibility.
I mean Perl5 is still mostly backwards compatible back to the original version released in 1987.
(There were a few rarely used bad features that should have never been there which have been removed.)
The way it does this is by having you specifically ask for the new features, if they would otherwise break code.
I think the takeaway is that if you want to make breaking changes, make a new thing and turn the old thing over to a maintenance team. If after a while you learn some things that could improve the old thing see if they can be incorporated without breaking compatibility or if the new thing is really so much better people will switch.