In Akka, if you really want to do true async then you're better off using continuations and `PipeTo` (which pipes the completed output of a Task into an actor's mailbox, often its own mailbox) then trying to await.

If you have a use-case where you absolutely need to wait on an Ask operation before you continue with the rest of your message processing, you should be able to do that without fighting the framework IMHO.

async / await are awesome, don't get me wrong, but they really pave over the Actor model's parallelism nuances with a brute-force approach - you really need more fine-grained control to do it properly. This is why `PipeTo` is pretty awesome - that allows the rest of the message handling to be done outside the Actor's OnReceive method, since all of the state needed to finish processing the request is part of the closure `PipeTo` uses internally. That's the way I'd recommend doing async message handling at scale.

The only way to tell if an Actor is waiting on a Task or not would be to have a handle on the TaskCompletionSource object itself, which to do at scale would probably require a custom `TaskScheduler` plus a state table for tracking which Actors are waiting and et cetera. Even then I'm still not quite sure if it could be done.

I'm not opposed to moving this code into the mailbox though and giving it its own priority queue - that detail would really need to be part of a mailbox base class though, just so it doesn't need to be re-implemented on every mailbox implementation (which is why I chose to do it inside the ActorCell.)