Yeah its a shame about gevent's portability. Its a shame that Python 3 can't go the route of making it a valid approach by brute force.
My fear of course is that Twisted, which is a twisted, unpythonesque API becomes blessed. And if you round the edges of the API and rename stuff, then you loose source-compatibility and suddenly you might as well have blessed something cleaner and smaller instead. Tornado might have been it, although it started small and beautiful but now its no faster than Twisted and its feeling decidedly rough again.
If you want to read a file from disk, you typically can't say "tell me when the file is ready for reading". You have to give the system some buffer(s), and say "read the file into this buffer and tell me when its done"; that's completion-based.
When twisted and so on were written non-blocking IO was for sockets and was ready-based.
Basically, on windows there just isn't good scaling ready-based non-blocking IO though.
Windows has solved the async IO problem in a different way; it got IO completition ports, which are completion-based.
And on Linux, non-blocking file IO (a new and rare beast, giving 50% improvement in my own hellepoll signalfd-based prototypes, but still an API I dislike to be honest) is completion-based.
The signalfd trick is Linux of course. On windows, you have to expose a completion-based API.
Twisted does have an ICOP reactor but...
The first thing people do with a ready-based API is actually read the bytes and present reads to the user a completion-based API based on some protocol-specific envelopes; and for writes they present a completion-based API to the user and then buffer those bytes user-side and feed them to the ready-based API when its writeable.
Its far cleaner and simpler to present a completion-based API to the user, and under the hood, on some platforms, map that to ready-based and ideally edge-triggered.
I think completion-based is the natural API for programmers, and exposing the ready-based API that some platforms have is too low-level and subject to platform-specific intricacies that we don't want to push onto the user.
Libevent 2 explains this really well in this blog post: http://google-opensource.blogspot.se/2010/01/libevent-20x-like-libevent-14x-only.html
See also http://tinyclouds.org/iocp-links.html