Big detail you've ignored here: how do you facilitate using a "named arguments edition" crate from a "no named arguments edition" crate?
(I believe one of the existing edition requirements is that it should be possible to write code that compiles without warnings on two adjacent editions, so a wholesale switch based on edition wouldn't be allowed per that guideline. But for the sake of the above question, I assume that's a solved problem via using rustfix to update and a system like Swift/ObjC to provide both the current "no named arguments" and a "named arguments edition" view of std.)
The easy example here is, again, HashMap. Currently, we have the construction functions HashMap::new(), HashMap::with_capacity(usize), HashMap::with_hasher(impl BuildHasher), and HashMap::with_capacity_and_hasher(usize, impl BuildHasher).
With named arguments, I'd poentially expose these as HashMap::new(), HashMap::with(capacity:usize), HashMap::with(hasher:impl BuildHasher), and HashMap::with(capacity:usize, hasher:impl BuildHasher).
If I write that API on edition20XX with named arguments, the crate still needs to be usable from edition2015 and edition2018.
You could just require me to provide the with_capacity_and_hasher name, but that's basically requiring everyone to write backcompat unique names that (trending towards) nobody will use, because for some reason the compiler doesn't use name mangling to handle that case? (From the POV of 20XX where nobody really uses old editions anymore.)
This sounds perfectly fine if you don't care about current editions using future editions' crates (they should just upgrade!), but Rust does care about that.