I did not understand the highly synchronous, sequential, blocking behavior of the code examples. That would absolutely make the events example not work. Or is it implicit that an asynchronous operation would replace today's blocking `next()`? That `itertools.consume()` or the final `next()` would provide an async upgrade, similar to the way Unix's `select()` works? That was never explicitly mentioned...but is the only way this pattern would make larger sense / scale usefully.
If we're talking about a general purpose event provider/consumer API that takes into account that some event sources will be voluble, while others will be almost always silent/blocked, then that's a real upgrade. It could bring a real event-oriented capability to generators. You see bits and pieces of that now--attempts to use generators with greenlets and coroutines, say. But until the 3.4 asyncio work, GvR hasn't seemed sufficiently interested/invested to make a big step forward on event processing idioms. Now he is.