> Please consider my patches instead; it seems our patches crossed.  Merging is now difficult because I already submitted my version to Tulip.

That's fine, I don't think there's a point into maintaining a
standalone patch for now: we can see how it goes with Tulip, flesh out
the API and merge it when it's ready (or when Tulip goes in)?

> Also my version makes fewer syscalls when unregistering a FD that has both read and write events registered.

It did it on purpose, because I wasn't sure whether kqueue ops can
accept more than one filter at a time.
If that's the case, then you can do the same thing for register().

> Regarding the _Key return value: I think it's asking for trouble if the signature of the base class differs from that of the subclass.  The return value may even be useful occasionally.

Agreed (but then it might be better to change _Key to Key if it's public).

> Given that no spurious FD events are now reported by the unittests, I'm not sure that it is useful to log and ignore them; it may be better to have the exception be raised, as it might expose an app bug, and in my experience it usually ends up in an infinite busy-wait loop once it happens.

Sounds good to me.