The Tokio team has been very active on that front. Recently, we've shipped a new strategy to improve the cooperative scheduler (https://tokio.rs/blog/2020-04-preemption/), and a bunch of other new utilities (https://github.com/tokio-rs/tokio/releases/tag/tokio-0.2.12, https://github.com/tokio-rs/tokio/releases/tag/tokio-0.2.11).
Standardization can be extracted once proven. This is how `std::future` came to be.
async-std aims to do that last sentence as cleanly as possible, without having to support a legacy interface. I found it builds faster because of that and that's why I chose it.
smol (the new kid in the block) aims to async-ify network types by simply wrapping them in Async<T>. It also aims to be as few lines of code as possible.
They are all different approaches to the same problem. The ability to experiment with different approaches is precisely why Rust doesn't have a prescribed async runtime (or prescribed error types, or many other things).
If merely solving the problem is all you care about, pick tokio. It should be able to use async-std crates, but async-std can't use it. smol can use anything but is a bit unproven.
A month ago I wrote a blog post about the evolution of async Rust and its async runtimes. Hopefully this answers your questions!
https://stjepang.github.io/2020/04/03/why-im-building-a-new-...
edit: my question may not be formatted correctly, but basically I am asking whether there is cooperation between the 2 projects, or they are competing each other