Personally, I prefer languages that make small incremental breaking changes, as it prevents cruft from accumulating over time.
The important thing is to provide a migration path (e.g., begin by marking something as deprecated). Then provide refactoring tools to help migrate or interface with legacy code.
I think C++ would have been much better off had it been willing to do this. Paraphrasing Stroustrup: C++11 has within it a smaller more elegant language that's trying to break free.
Being able to run old legacy code is one of the most important arguments for C++. Every new feature is add-on (not "upgrade" and not "migration").
At the fast pace things develop for Rust I hope that the language will have a good way to handle Rust 2.0 code together with Rust 1.x code. IMHO providing practical tools for an upgrade path is something that should be thought of before releasing 1.0.
Objective-C is a good example of successfully migrating the language forward. Breaking changes were introduced slowly. Library APIs are marked as deprecated several releases prior to removal. The compiler warns you of their use. Automatic reference counting can be turned off for legacy files, but a tool is provided that will help you convert a class to use ARC.
Code written in ObjC a couple of years ago will likely not run today without modifications. But overall this has been a net positive for the language. It's actually become really pleasant to use. And is in part why Apple's platform has thrived.
I think optimizing for the past is the wrong thing to do. If your language is successful, then most of the code is yet to be written. So if your choice is between making future code easy to write, or not breaking legacy code, then you should err on breaking legacy code and provide deprecation/migration tools.
The important thing is to provide a migration path (e.g., begin by marking something as deprecated). Then provide refactoring tools to help migrate or interface with legacy code.
I think C++ would have been much better off had it been willing to do this. Paraphrasing Stroustrup: C++11 has within it a smaller more elegant language that's trying to break free.