Hi there!

I've just stumbled upon this behavior and I was also surprised by the fact that the second await simply returns None.

After fiddling around for a while, I noticed that if I wrap the coroutine object using asyncio.ensure_future() or asyncio.get_event_loop().create_task(), the same result/exception is returned by multiple await expressions.

I haven't looked at the patch, but the intent to make the 2nd await raise a RuntimeError seems strange for several reasons:
- it's inconsistent with the Future/Task interface;
- it's quite common to await a 2nd time to get the coroutine result after calling asyncio.wait(...) using ALL_COMPLETED or FIRST_EXCEPTION;
- as mentioned in the mailing list the await keyword in C#/Hack/JS which inspired the await keyword (as per PEP492) returns the result/exception multiple times.

I put up a Gist that shows the inconsistency: https://gist.github.com/AndreLouisCaron/db2965aae095f5c85dd5

Here's an example of asyncio.wait() I was referencing:

async def main()
    f1 = foo()
    f2 = bar()
    asyncio.wait([f1, f2], return_when=asyncio.FIRST_EXCEPTION)
    print('1:', await f1)
    print('2:', await f2)

I also noticed that there seems to be some intent to avoid making a distinction between a normal function returning a future and a coroutine function from the point of view of the caller.

If the patch is merged as is, I will always need to use asyncio.ensure_future() on all coroutine calls before asyncio.wait() because the result is inconsistent depending on the implementation of foo() and bar(): if they return futures, I'm OK, but if any of them is a proper coroutine function, I might get RuntimeError exceptions.

Any chance you can consider changing the patch to make awaiting a coroutine's result multiple times a valid pattern?