Rust 1.0 will be stable and will cease making breaking changes.
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.
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.
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.
Just to nit pick, but there were actually breaking changes introduced in the latest C++ standards. See http://stackoverflow.com/a/6402166/101999 for a decent list.
Can you comment on that -- possibly entirely incorrect -- concern I have about Rust's development? Are we going to see Rust 2.x popping up in six months?
Furthermore, and this is speculation, since again, we haven't talked about it as a group, but I wouldn't imagine a Rust 2.0 where it's like breaking changes are today. I would imagine a very long period of deprecations, a nice upgrade path, and all that jazz. Nobody likes when the entire world changes out from under them all at once, and sudden, massive changes are something we're trying to avoid with the release train model.