I was vague and unclear, entirely my fault. I really want Rust to be successful, I just think some of the decisions being made are shortsighted, so I will watch after release to see if I am correct, hope I am not.

> What is the impending 1.0 release if not that? We've been very clear all along that 1.0 means language stability. I see no "hand-waving".

I guess I don't consider "stability" and "backwards compatibility" the same thing -- in the "stability as a deliverable" post, it was specifically referenced that rust will "continue to evolve at a rapid pace and even accelerate!" (quoted from memory, sure it is somewhat off).

I think a constantly growing language (no longer changing cause old code has to work, but growing... which seems worse) and the fact that libraries will opt into new features and bundle use of those features with bug fixes will mean that the entire userbase is on a 6 week upgrade cycle -- 8 or 9 upgrades a year. I consider that a mistake. Furthermore, I consider the idea that the channels will not fracture the community to be very naive. I expect a lot of libraries will just live on unstable and tell users to "come with them".

> Why would you be worried that we're following precisely the schedule that we said we would?

You are correct and that was unfair. I can't fault the team for doing what they said -- even if to an outsider it seems like an insanely late time to be doing these types of refactoring.

  > no longer changing cause old code has to work, but 
  > growing... which seems worse

It should be mentioned that the "features" that Rust has yet to implement are largely not of the nature of "wholly new concepts that will drastically change the language", but tweaks to existing features to make them more performant and more ergonomic. Such features include lessening the restrictions on the borrow checker, making it possible to return unboxed closures constructed in a lower stack frame, and improvements to user-defined smart pointer types to make them equal to first-class constructs (such as the ability to do `Rc<Trait>`). "Growing" here means refining the language as it exists, not succumbing to featuritis.

  > the entire userbase is on a 6 week upgrade cycle -- 8 or 
  > 9 upgrades a year.

I don't see how this would be the case. If you write a lib for Rust 1.0, the intent is that it will continue to work for all users on Rust 1.1, and 1.2, and 1.3, and so on. No need for the lib author to explicitly upgrade, and hence no need for lib consumers to upgrade.

  > I consider the idea that the channels will not fracture 
  > the community to be very naive.

Nobody is expecting the entire Rust ecosystem to transition to stable overnight. Rust 1.0 presents a very conservative foundation upon which you might want to base your code. If you do, you are rewarded with future stability for all 1.x (and also means that even unstable users will be able to use your code without breakage). This means that the stable Rust ecosystem will gradually accumulate over time. This gradual transition process is fully expected and encouraged.

Rust 1.0 does not mean "the language is done and perfect". It means "we know you're tired of breaking changes, so we've set aside all these enhancements that we were planning on adding so that we can achieve stability sooner, with the expectation of landing those features backward-compatibly at some later date." Rust could easily spend years and years and years in an unstable state, seeking perfection, and there are some in the community who still wish that were the plan. But as someone who's been using Rust since 2011, I'm in agreement with the core team: stability now, evolution over time.

> "Growing" here means refining the language as it exists, not succumbing to featuritis.

In no world does "we expect that pace of change to accelerate" mean "we expect subtle refinement of the language". Refinement or polishing generally isn't something that "accelerates change".