You also can mix and match rust async/await.
The problem is not the executor of the futures itself.
But the "Reactor" which is needed to do async-io and the "TimerScheduler" which handle thinks like `.delay(..)` or
non os-native timeouts.
What you often can do is having a `Reactor` and time sheduler running for all runtimes involved.
This e.g. works very well with async-std due to it's simple design.
But for tokio it's more complex as you need to provide the reactor and some other hints through something comparable to thread local variables (instead of globals).
This is where the `tokio02` compatibility feature comes in which makes sure to provide access to tokios reactor in the async-std future executors.
Another problem is the global `spawn` method. You normally don't want to run two future executors but as long as their is no abstraction layout over spawn you will have to. Furthermore tokio does a lot of fancy things which you likely will never see in a generic API which is another problem.
For example normally if you want to do blocking code you spawn this in a thread pool to not hinder other async code. But in tokio there is a way to "overlap" the pool of blocking and non-blocking code, basically up to n worker threads of the non-blocking thread pool can be marked at blocking at a time. This is one of many thinks which increase complexity which other runtimes like async std avoided due to it not being worth the additional complexity in >99% of the cases.
Except that tokio is to some degree written for that 1% of cases where all that additional complexity is needed. Because a lot of dev time come from people which work for a company which does need it for their product.