I think this is too narrow for Rust to tackle directly. It addresses only one example case out of the general problem of optimizing generic code for specific cases. This makes it limited, e.g. if I have an unordered Rope type, I may have the same problems, but can't use the UnorderedVec any more.
For iterator adapters, std already has specialization. The specialization being stable (hopefully some day!) could help 3rd party implementations like rayon.
Other features, like ability to mark functions as "pure" or "no-panic", and ability to specialize on that, could enable more aggressive implementations.
I'm aware this might look like an instance of the X Y problem, but this is actually "just an idea" I had. I've posted it because it'll be useful for someone. If anyone knows/has more use-cases, I'd like to read/hear about them!
It could be said this is "a solution looking for a problem", and I (sadly) agree. u/kornel has mentioned specialization, which (if I understood correctly) might make this proposal (mostly, not entirely) obsolete
There doesn't seem to be a specific one. But relaxing constraints typically allows one to make tradeoffs that otherwise couldn't be made. Such as iterating different portions in parallel. Or storing portions in different parts of memory or in different types of memory. Or buffering updates in an unordered memory mapped store before sorting, sharding, and flushing to disk. Or allowing for a different algorithm to be substituted in that may not exhibit the same numeric stability guarantees.
I can imagine some hyperscalar hardware could benefit from language level constructs that help utilize it, but who knows.
I also had reflected-binary code in mind. Incrementing an int in gray-code is more energy-efficient. However, the point is moot, as (most) computers waste energy waiting for main-memory, and a CPU with native gray-code instructions will (typically) be connected to a memory-architecture that supports gray-code (and even if the mem doesn't support it, then the MMU will convert the pointers to positional-numerals anyways, negating all power-savings )
)