I did look at that, it's "just" doing things like wrapping the system-provided APIs for notification. It's useful in scenarios where you might be reading from 1000 sockets at once, all of which are trickling data into a dozen server CPU cores doing the processing.
The Read2 API is much simpler than this conceptually, and is only tangentially related. E.g.: it might be feasible to extend it with a fn peek_any(...) API somehow via a related trait or something.
PS: The Performance of Open Source Software | Parsing <span class="caps">XML</span> at the Speed of Light was one of the reasons I went down this rabbit-hole. I've recently been thinking about how to parse XML as fast as possible for use-cases similar to ripgrep. The common-case is almost, but not-quite, pass-through for a lot of the bulk data processing. If the encoding is UTF-8, which it usually is, then you can often pass the text onto the reader as-is. Except you can't, because of   and the like. You can also often pass through the text as &str, but just like with the mmap situation, that can get a bit iffy in memory-constrained environments.
It's an interesting design problem, that's for sure! 8)