I would suggest languages facing the same problem learn from Perl 5's success, rather than the various failures of Python 3.
Every† minor point release of Perl 5 creates backward-incompatible changes. These can be opted into individually, or on a per-file basis by simply specifying the version of Perl used. It all works. Differently-versioned Perl code can call each other as much as it likes.
There was never any reason why Python 3 needed to be anything other than Python 2 with this at the top of the file:
use Python 3.n
use Python 2
[†] Perhaps not literally every, but it may as well be.
There are many options with pros and cons. Python was aware of them. They made what looked like a reasonable decision to take a different paths. On hindsight we know of the problems but you could not predict them with confidence in advance. (some may have predicted it but they would admit to guessing if they are honest)
Sure, not interested in changing the past, for many reasons not least of which is that it appears to be impossible. The Python team surely did not go in to Python 3 blindly, but they botched it anyway.
What I mean to say is that Python as a negative example only goes so far, because an example of failure isn't a template for success. So "don't do what Python did" carries limited value for a language looking to make breaking changes. For a language looking to make a major point release, that's the future, and the future can be changed; this is what I'm interested in here.
"Do what Perl 5 did" (and do not do what Perl 6 did, up to the point it got renamed) is a great place to start, however, because it worked, works, is working. Languages are different enough that it isn't a completely transferable experience, but there's a lot to learn there.