In my view the separate interfaces increase the long term damage that new libraries are creating every day, and it should be higher priority to resolve it together before implementing new features in either of the two libraries (async-std and tokio).
The choice of not using all of futures for their interface is outspoken the strategy of tokio. We have encouraged them to prefer the futures layers, but we don't see the work happening.
So, to answer your question: we are not working with them, the place of collaboration is futures-rs.
But this cannot made work generically in the current ecosystem, as there are no common abstractions here. We can't come up with those unless we have buy-in from other players.
For applications, that doesn't really matter: you pick one Listener type and you're done. Applications aren't very generic.
For libraries, that's harder, but there's strategies around that make it feasible to work with this situation (mainly: injecting the exact type to use into your library).
Finally: there's a flag in async-std called "runtime". If you turn it off, you can use async-std without that behaviour, at the cost of having to bring your own runtime.
Especially for things like an actor system, I would recommend to not use either, but instead spawn a dedicated number of threads handling the actors. This allows you to be specifically optimised to the problem. bastion is a great example for that.
async-std ships a second library called "async-task", which implements just the task/future allocation component and allows you to quickly implement your own runtime.
Full disclosure: I'm one of async-std's maintainers.