Let me just start by saying that I understand that point of view, and I find it completely reasonable argument. But I don't think it's the most important PoV here.
The way I see it - Rust community generally tries really hard to provide the best possible APIs. And all things equal, having an API that is more deterministic and predictable is just better than having an API that is less deterministic. Rust did have an implementation that was effectively both fast and strictly defined and deterministic.
Saying that "something was documented, and it's user fault for not being aware of it" is technically absolutely correct but is ... for a lack of a better way to describe it ... just very C++-ish thing to say.
The reality is that developers make mistakes like these all the time, and part that people love about Rust is that it helps them as much as technically possible to do the right thing.
We can't just look at being technically correct here. We used to have an implementation that behaved in certain predictable way. Had it been completely not deterministic (like
HashMaps are for important security reasons), developers would pretty quickly discover it in the early phase and fix their code. Changing it between rust versions is ... just not great, especially for marginal perf gain.
And even if it wasn't for changing the current behavior to a new one: the predictable behavior, is just better from a perspective of reliability, determinism, defensive programming. Even if we weren't changing the behavior, but writing this API from scratch I would vote for making an API that is more predictable.
Another way I think about it is with compassion: Could I have made a mistake like that? Yes I could. Could Rust have saved my distracted and ignorant butt? Yes it could. So why wouldn't it?