A bit late to reply, but if you see this know that you made some good points. Detesting it is probably a bit much, but I do find the pattern cumbersome. Do you use tokio in wasm? I haven't, but I've seen issues for wasm support closed because of tokio. That could have been an excuse. Again in embedded what I run into is that embassy is the standard executor, and is useful, but so many crates bring in tokio when they don't really need to that they are poisoned for embedded use. Lastly it isn't just being superfluous, it is a dozen or more crates bringing download size and attack surface that don't solve any problem I ever actually have, or mostly any problem the crate author had. So really what you helped me realize is that it isn't async/await I dislike at all, it is just tokio being the defacto implementation of it.
I don't think tokio itself is going to be the issue for wasm or embedded, but if the crate you're importing uses tokio it usually means it's expecting to have access to an OS with file and network access, none of which is going to work in wasm or embedded in the first place.
But I agree with you on the fact that Rust ecosystem (the part of the ecosystem that uses std at least) is tied to tokio is not a good situation. In theory we could have crates being agnostic about the executor, as they aren't supposed to execute anything, just expose the futures and the top level crate is the one driving the execution, but AFAIK the way tokio is designed currently makes it impossible to separate the concerns. The Rust team would like to change that, but it's not trivial and it would require collaboration from the tokio team, which is not granted.
