I'm not too well-versed myself, these are mostly parroting what I gather from blogposts. 1. Yes! There was even a semi-official solution for that: https://gith

I'm not too well-versed myself, these are mostly parroting what I gather from blogposts. 1. Yes! There was even a semi-official solution for that: https://github.com/rust-lang/impl-trait-utils https://github.com/rust-lang/impl-trait-utils 2. No need for boxing and allocations and pinning the box, and dyn also limits the traits to the dyn-compatible ones. But yeah, maybe it wasn't too bad before? 3. I'm not convinced it's THE reason, but that is A reason. Besides that, there's at least the split between io_uring (completion) style APIs and epoll (readiness) style APIs. How to square that circle seems to be like an open question... Then there's the split between multi-threaded runtimes that require Send/Sync and single-threaded ones. Then finally, there is no standardized way to spawn new independent tasks, so every runtime invents their own. We'll see, but at least the current developments (impl Traits in traits and return type notation) would allow there to be a larger set of compatible types and traits. Whether that will solve the whole balkanization issue is beyond me, but at least it fill in some gaps. 4. Yeah, that seems to be a hard problem. Niko Matsakis and withoutboats have been blogging about some thoughts and designs to fix the ergonomics, and I think they will get better, but it might take years. I think the situation will slowly improve, but indeed it seems like it'll take years. But at least now we have another "round" of stabilized features that will remedy some of the issues. Maybe, after playing some more with those new tools, we'll have a better understanding about the remaining ones, and what is really needed to fix them.