Aiming at perl level stability seems like a bad idea at version 1.0. There will be mistakes - some of them really horribad.
Wouldn't it be a better idea to aim at some kind of Rails level stability, with actually expecting 1->2 to be a total rewrite, 2->3 be a massive undertaking and 3->4 be a quite simple undertaking and then accumulate stability as the good ideas pile up over time?
Different approaches to stability attract different people. I wouldn't touch a 1.0 that promised 1->2 to be a total rewrite. With a 1.0 that promises backward compatibility, I'll be sure to look into it. More importantly, it's true for whole organizations employing hundreds or thousands of programmers.
On the other hand, some people like to work on things that "will always improve", and where compatibility will never be a reason to tolerate a suboptimal design decision in the long run. Which works especially well if their taste matches the taste of whoever is charged with evolving the thing. One could argue that Rails 4.0 or 20.0 beats any 1.9999 version a backward-compatibility-centered system could ever deliver... and one could argue against it.
I'm obviously happy that Rust takes the approach that suits me :-)
I almost want to liken this attitude to Lua's approach to stability: The general look of the language will remain the same, but some base-line things may change between releases. That's the impression I got from the OP. (Granted, Lua gets used in a far different environment than Rust, so people holding onto an older version for their own projects is not a big deal in Lua. I don't think Rust wants to engender that attitude for its use. I'm not sure, though; I haven't really used Rust nor spent any time in the community.)
Wouldn't it be a better idea to aim at some kind of Rails level stability, with actually expecting 1->2 to be a total rewrite, 2->3 be a massive undertaking and 3->4 be a quite simple undertaking and then accumulate stability as the good ideas pile up over time?