This is not rocket science. You can do it too. Go read http://graydon2.dreamwidth.org/1597.html written by Rust's original author.
But if you consider the entire ecosystem (see http://pkg.julialang.org), many packages that you might rely on, especially for simple operations, might break.
Most of the breaking changes are developed in branches and merged when completed. Again, overall the source management is also following the best practices in this sense.
I didn't really want to get into too much detail because for me most of the arguments made are ok, but it's an ongoing development effort. When new ideas are proposed, I want them to be considered, not dismissed as "breaking changes".
It is a gut wrenching feeling when code crashes in production and it is my compiler to blame. It seems so much more shameful to me then if a library or service of mine crashed, not that that isn't shameful as well.
Do I need to loosen up?
As I've used more modern languages with better type systems I've moved away from high test coverage and towards writing code that simply can't go wrong (or at least, that is exceedingly limited in the ways it can go wrong); http://spin.atomicobject.com/2014/12/09/typed-language-tdd-p... is a well-written explanation of something very close to my current approach. So I wouldn't put the emphasis on branch coverage or fuzz testing that you do. But I absolutely agree that you should have a very high level of confidence in a compiler before you ask people to use it, substantially higher than the level of confidence required of a library or service.
[0] http://words.steveklabnik.com/rusts-documentation-is-about-t...
Also the ability to easily search both the standard library and third-party libraries is probably going to be needed soon if nothing experimental is going to be available in the "standard track".