Yes I think we agree, though I'd quibble about the async syntax; I use it but I have philosophical concerns about it. But I do think tokio is on the whole well implemented. But it is not a good thing for a single runtime to dominate the language like that.
I've at least thought-experimented with what it would take to write my own code agnostic enough that it could run on both e.g. tokio and e.g. monoio etc. and, well, it just can't happen. Even if you find neutral/unbundled implementations of locks, channels, utilities, to depend on instead, you end up stuck at: task spawning, and any kind of I/O. The former, to me, is a glaring absence from the language standard; async should not have gone out the door without support for it.
I can't argue too much on your view of the syntax. I employ the weasel word "fine" because my experience with it is that I have little to no trouble understanding and using async Rust syntax: I can read and write async Rust and conceptually grasp what is likely going on in the runtime. I have to allow that perhaps it isn't sufficient, and maybe even that this is a factor in the runtime problem.
But there are other, non-syntax issues, such as synchronization primitives, IO events, etc. that are clearly underspecified. No maybes about it.
I've at least thought-experimented with what it would take to write my own code agnostic enough that it could run on both e.g. tokio and e.g. monoio etc. and, well, it just can't happen. Even if you find neutral/unbundled implementations of locks, channels, utilities, to depend on instead, you end up stuck at: task spawning, and any kind of I/O. The former, to me, is a glaring absence from the language standard; async should not have gone out the door without support for it.