SE_SLEEP is actually what allows us to ensure that they're not lost and for a number of cases where these things are used, a lost event can end up being pretty unfortunate. I believe that a mechanism like inotify has to basically say that events were lost and you need to rescan whatever the class of event you're looking for needs to be evolved if we want to actually have consumers that can realistically handle themselves in the face of low memory.

That said, all of this is already executed from an explicit notification thread that mac creates, so I don't think the risks of having a little bit of additional blocking are going to be too bad. At least, to date, it hasn't proven to be a source of problems for us, though I can't say we've exhaustively hit all possible issues such a choice could have either way.

Historically sysevent has always been best effort delivery.  That was, IIRC, part of the original design that I seem to recall Cynthia created -- admittedly I'm remembering stuff from the Solaris 8 time frame (when sysevent was created, which was mostly in support of dynamic reconfiguration and in particular discovery of newly attached resources.)
One of the concerns raised by Cynthia, again per my recollection, was that if a slow event consumer was present, it could gum up the works.
Now, having said all that, this is happening before the event is generated, so I guess it's ok.  Generally if we can't allocate memory the whole system is pretty unusable anyway...  so I'll agree to let this stand as is.