Yes, that's what I was suggesting.

Looking at tornado they do the stop between callbacks/matured-scheduled and events.  That approach seems somewhat arbitrary to me at first glance but tornado is very mature and they usually have good reasons for what they do.   

The notion of always completing a cycle seems more apt to me;  Ie. your first design.

A compelling thought experiment for allowing stop() to be lazy is if a user could somehow know when stop() was going to run or when it had been run.  The nature of ioloop programming prevents you from knowing when it will run and because stop() has no return handle/future/task a user can't actually know when it did run.  Ie. there is no way to await/add_done_callback on it, so baring hacks that bookend a stop() with marker callbacks it should be, as you said, sufficiently vague to justify a (more) lazy effect.

--

I more or less agree on the s/cancelled/done/ changes.  I'm using a similar monkey patch in my libraries to dance around this issue right now.  I still don't exactly like the idea that code is written with an explicit expectation that it could be pending or cancelled, but then must also be inherently prepared for spurious done callbacks.  This seems like a borderline contract violation by add_writer() and co.  I suppose that add_writer() is primarily targeted at streams and the case of an EINTR in a socket connect() is a more a one-shot.  Tough call.