Unifying surface features increases the combinatorics of interactions between traits, lifetimes, generics, specialization, and macros and leads to surprising edge cases.
Editions buy migration safety and let the standard evolve, but they do not shrink the mental model newcomers must carry and they force tooling and libraries to support multiple modes at once, which is a different kind of maintenance tax than evolving C++ compilers and feature test macros impose.
Require RFCs to include an interaction test matrix, compile time and code size measurements, and a pass from rust-analyzer and clippy so ergonomics regressions are visible before users hit them.
> and they force [] libraries to support multiple modes at once,
I'm not entirely sure I agree? I don't think any library except for the standard library needs to "support multiple modes at once"; everything else just sets its own edition and can remain blissfully unaware of whatever edition its downstream consumer(s) are using.
> which is a different kind of maintenance tax than evolving C++ compilers and feature test macros impose.
I'm not sure I agree here either? Both Rust and C/C++ tooling and their standard libraries needs to support multiple "modes" due to codebases not all using the same "mode", so to me the maintenance burden should be (abstractly) the same for the two.
> Require RFCs to include an interaction test matrix, compile time and code size measurements, and a pass from rust-analyzer and clippy
IIRC rustc already tracks various compilation-related benchmarks at perf.rust-lang.org. rustc also has edition-related warnings [0] (see the rust-YYYY-compatibility groups), so you don't even need clippy/rust-analyzer.
[0]: https://doc.rust-lang.org/rustc/lints/groups.html