> 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.
> Even if a crate compiles under a single edition, exported APIs often avoid edition specific idioms that could cause friction for consumers compiled under older editions.
Do you have some concrete examples of this outside the expected bump to the minimum required Rust version? I'm coming up blank, and this sounds like it goes against one of the primary goals of editions (i.e., seamless interop) as well.
> So while technically each crate chooses its edition, ecosystem reality introduces cross-edition friction.
And this is related to the above; I can't think of any actual sources of friction in a mixed-edition project beyond needing to support new-enough rustc versions.
> Rust tools such as rustc, rust analyzer, rustfmt, and clippy must understand edition dependent grammar and semantics simultaneously.
I'm not entirely convinced here? Editions are a crate-wide property and crates are Rust's translation units, so I don't think there should be anything more "simultaneous" going on compared to -std=c++xx/etc. flags.
> Over time this creates a cumulative maintenance burden similar to maintaining compatibility with many historical language versions.
Sure, but that's more or less what I was saying in the first place!
