I could have put some more thought into this response.

As Rust becomes more popular while we try to bring home the last few major changes, we've had this problem a few times, where the broader community is surprised and partially shocked and disappointed at a change that has been brewing for a while.

Certainly, more effort could be put into messaging and explaining how big changes are going to effect users. Figuring out how much, and what sort of, messaging is sufficient is not easy, and somebody is always going to find something objectionable about nearly everything. Additionally, Rust is still in an alpha state, in heavy development. The project is not in production mode yet.

We're always learning from mistakes and evolving the process.

Finally, Rust is in the home stretch. In some sense, we're at a stage where we need to hurry up and just get it done, at the expense of some community fallout along the way. If Rust is good, the ill will from the churn will be forgotten in time; if Rust is bad it will die. With the attention Rust is attracting, community momentum wants Rust to stop changing, but Rust must change a bit more. Rust needs to get to a point where the design can be justified and maintained for years to come, before its own popularity forces it to slow down.

Thanks for the detailed response. I understand that having to deal with this sort of situation instead of working on bringing the project closer to fruition must be very annoying from a core developer's perspective. Sorry for contributing my part to this being dragged out further.

To clarify, what has distraught me the most about this change is not even the change itself (although I do think that, however small or warranted on its own it may be, it may have long-term ramifications that need to be considered much more carefully), but the way the process seemed to diverge from the fairly open and inclusive discussion that seemed to regularly take place in the past. This change may well have been brewing somewhere for a while, but from the point of view of someone who is not in the "inner circle", what was perceivable of it essentially was the thread I linked above some 16 days ago (which was remarkably full of responses by apparent "insiders" that aimed to discourage people from discussing the topic at that point in time) and the thread announcing the RFC, in which even some of the most basic questions needed for a casual observer to understand the tradeoffs were unanswered when the proposal of the RFC was mainlined something like half a day later.

The end result is something that looks similar to what happened with GNOME 3 to someone who was in the opposing camp in both cases, where the "in-group" at some point decided that they had identified a development agenda of utmost importance to what has in fact been part of the central mission of the project all along, and increasingly came to send the message that they held disagreeing members of the "out-group" to be obsessive hecklers and people who should just get out already if they don't like it - although nothing says it has to end up like that, where this took the state of Linux desktop environments is easily observed nowadays.

When considering the overall lifecycle of a project, the number of remaining "difficult decisions" is a far more accurate metric of completion than code or concept. Frustratingly, it is pretty much bound to increase towards the full end of the scale of the latter when the development process is a highly public affair. People wouldn't argue this topic with such ferocity if it wasn't for their appreciation of your work so far and high expectations for this project; please don't let that go to waste by shortcutting the decision process when you have come this far.

Yeah, I've read the document, and I would hope that most other people who proceeded to debate the topic did as well. I honestly don't think that it does a commensurate job of presenting the case for it (and after reading many of the comments by proponents, I certainly am under the impression that there is a strong case for it; I just still think the case against it is stronger). A lot of the comments also show widespread uncertainty about the silent assumptions; I, for my part, am still at a loss as to why something like Cons(1, ~Cons(2, ~...)) is not an interesting or common use case according to some proponents (not necessarily restricting the question to cons-cell lists - the invoked universal utility of sharing tails, for instance, seems far less universal across the practical use cases of many other data structures).

I can't quite tell from your last sentence if you realise this, but ~ doesn't provide sharing at all: ~T/Box<T> acts like a T in almost all ways, except it is guaranteed to be pointer sized (hence its use in recursive data structures, to allow them to exist without being infinite large). A pointer like Rc is required for sharing.

Do note that the Cons cell construction becomes `Cons(1, box Cons(2, box ...))` which doesn't seem particularly bad.

Thanks for the clarification; I do realise this. The context in which the question arose was that several of the "for" arguments seem to state something to the effect of ~ being rare in code due to only occurring in type definitions.

I believe that was just addressing the fact that the type `Box<T>` is more annoying than the type `~T`, since the `box expr` replacement for the `~expr` expression is relatively nice (admittedly I wasn't following the discussion in great detail).