I agree with Yury's ideas about the implementation of this feature. However, it is a bit confusing to have `asyncio.get_event_loop` defined as:

def get_event_loop():
    policy = get_event_loop_policy()
    return policy.get_running_loop() or policy.get_event_loop()

One would expect `asyncio.get_event_loop` to simply work as a shortcut for:

    get_event_loop_policy().get_event_loop()

The root of the problem is that we're trying to define 3 concepts with only 2 wordings. I think it is possible to solve this issue quite easily by renaming `AbstractLoopPolicy.get_event_loop` with `AbstractLoopPolicy.get_default_loop`. We'd end up with the following definitions:

- default_loop: current default loop as defined in the policy
- running_loop: current running loop (thread-wise) if any 
- event_loop: running loop if any, default_loop otherwise

Changing the API is always annoying, but in this case it would only affect the event loop policies. This is a pretty specific use case, and they'll have to be updated anyway in order to implement `set_running_loop`. asyncio.set_event_loop might be affected too, although it could be kept or deprecated.

Do you think it's worth the trouble?