> All this checking for coroutine-ness feels very strange to me. It's anti-duck-typing: [..]

Why is it "anti-duck-typing"?  Awaitable is an object that implements __await__.  With this patch coroutines are a separate type with __await__ (although, ceval doesn't use it to make things faster).

In asyncio we check for "coroutine-ness" only to raise errors if someone passes a wrong object, or to make @asyncio.coroutine work (which will go away eventually).

> Now, not only must it return a generator with the special coroutine flag, the callable itself must be of the right type [..]

Not sure what you mean here.  It doesn't matter what callable is.  It only matters if it returns a native coroutine, a generator-based coroutine, or an object with "__await__".

> Attempting to divide generators into awaitable and non-awaitable subsets is a complex solution to a problem that I'm not convinced is real.

Well, 'await' expression is a new operator, and it makes total sense to limit its usage only to awaitables.  Awaiting on a generator that yields a fibonacci sequence just doesn't make any sense, and *is* error prone.  I think it would be a major mistake to allow this just to make things a little bit more convenient during the transition period.

This particular patch does not divide generators in awaitables and non-awaitables, it introduces a new type for 'async def' coroutines.  All confusion with old generator-based coroutines and @coroutine decorator is here only because we try to be backwards compatible; the compatibility layer can be removed in 3.7 or 3.8.

> Was there a problem in practice with Python 3.4's asyncio in which people used "yield from" in a coroutine with generators that were intended to be iterators instead?

Yes, a lot of people were confused where they have coroutines and where they have generators, and this was even mentioned in the Rationale section of the PEP.