I seem to be writing a few of these 'clarification' posts...
Anyway, in my last post, I wrote "One partial solution might be to start planning a 2.0 release", I was deliberately cautious with the language, but not cautious enough. This part of the post has been picked up on a lot, and it was meant to just be a part of the post.
"2.0" can obviously mean a lot of different things. I think that a major breaking release would be a terrible idea and we shouldn't do that. I think that there is a problem if the language grows monotonically, I think that we need somewhere to experiment, and I think that our very strict attitude to backwards compatibility makes a lot of things difficult. But stability is super-important and having a strict attitude to stability has served us well.
I think that taking a slightly more flexible attitude to backwards compatibility might be beneficial in some areas. I don't know what that would look like, perhaps it would be an edition change with deprecated features actually removed; perhaps it would mean crates are binary compatible across versions but need to be compiled with different compilers (yeah, I know, binary compatible, lol); perhaps it means you need to run a tool over your code before running the new compiler. All of these things are in the '2.0 with mitigations' bucket for me. The key thing is that users are not in a Python 3 or Perl 6 kind of situation.
Somewhat orthogonally, I think there is a need for somewhere to experiment on Rust which isn't nightly. I lumped that in with a 2.0 idea in the post and that was a mistake. My thinking here is that for big features, there should be a place to experiment with implementations which is official but which does not imply riding the trains to stable Rust or inclusion in the distributed compiler (just flagged off).
Thanks to everyone who has pointed this out/discussed!