I think the current version, with its minor warts, is a very pleasant and consistent experience for the most part -- very much unlike C++. So I'm not sure what I'd change to such a drastic degree that it'd require such breaking changes.
And if I want to risk going too far, I'd also advocate for refactoring the type system to be slightly less generic in favor of chasing faster compile times.
Also, ideally the lead designer of SafeLang2.0 would be much more heavy on engineering experience than PL theory. Rust made a lot of tradeoffs that were beautiful in PL theory but are annoying to use on a day to day basis.
I honestly think rust is equal parts amazing ideas and mediocre ideas, and I think a slighky less ambitious language would still be almost as safe (world class compared to any other language) but 10x more fun to use.
Similarly, I’m curious as to what the details of a “slightly less generic” type system entails.
Changing Iterator to make use of Generic Associated Types.
Change std::env::set_var to be unsafe. Because using it in multithreaded program causes undefined behavior for any c code that reads the environment (which includes quite a few libc and posix functions).
Change channels to have a better API that is mpmc and closer to crossbeam.
And probably others I can't think of at the moment.
About `std::env::set_var()`, there was a proposal for a `#[deprecated_safe]` attribute that triggers a warning if the function is used without an unsafe block, and eventually make that a hard error in future edition.
Now, it may be something that still can be fixed and improved upon, but a Rust 2.0 with nicer async experience would be a big win.