Your second point has been a focus area for them for years, and we’ve seen it improve with async fn in trait, async closures, etc. Hopefully we see that continue to improve over time.
The third point has a solution in the works already (at least for crates.io). The accepted (I believe) proposal is that crates themselves act as “namespaces” and you can publish crates like bevy::render or hyper::utils that get loaded under some parent module by the compiler. Publishing crates with names containing :: would be constrained to those who maintain the parent crate (so bevy or hyper in that case).
Your second point has been a focus area for them for years, and we’ve seen it improve with async fn in trait, async closures, etc. Hopefully we see that continue to improve over time.
The third point has a solution in the works already (at least for crates.io). The accepted (I believe) proposal is that crates themselves act as “namespaces” and you can publish crates like
bevy::renderorhyper::utilsthat get loaded under some parent module by the compiler. Publishing crates with names containing::would be constrained to those who maintain the parent crate (sobevyorhyperin that case).