> You don't know what else that coroutine is waiting for, and it may be waiting for some I/O whose socket is registered with the other event loop. Since the other event loop won't make progress, you'd be deadlocked.

As an end user I know what my coroutines may be waiting for. It's out of question to expect an ability to reuse coroutine and its associated context in multiple loops.

> PS. If you have something you sometimes want to run synchronously and sometimes as a coroutine, you probably need to refactor it somehow.

We have a service that is responsible for reporting various stages about our application's lifetime. Most of the time app does not care about when (and whether) data will be actually sent, so we run this service in its own thread, the rest of the app just schedules coroutines in its event loop (hidden and managed by service's API). However sometimes it does care and moreover needs to do that synchronously (i.e. when we handle fatal / unhandled exception. In order to reuse remaining code that constructs coroutines, in the place of invocation we create a temporary event loop and use run_until_complete.

This is all practical problem. The conceptual problem is that current API is not flexible enough to create an event policy that would do something more useful that changing default type of an event loop.

Having the ability to get currently running event loop from within executing coroutine sounds pretty convenient and in my opinion would greatly reduce the amount of passing loops everywhere for end users (library developery, unfortunately, have no chance to avoid this).