Well, non-blocking sockets are simply rare and Windows and Unix have different philosophies. Windows is more asynchronous event driven, and Unix is more polling of filedescriptors (and mapping a lot to filedescriptors).
The windows eventloop mechanism makes it more flexible and pluggable. (to allow later added parts of a program to register themselves in the eventloop). It can receive and relay messages from a primitive that only got the handle of the eventloop, without requiring an own handle to be added to the loop.
IPC (to a certain degree) and file/sockets can both deal with the message loop. ICS is a typical windows solution that maximize usage of this layer.
This while Unix can't even seem to wait on two IPC primitives at the same time (no equivalent for waitmultiple). It can on two filedescriptors though, but not on filedescriptors and IPC at the same time. LNET is thus a typical unix approach assuming it is in sole control of the main blocking point (event loop) of the program.
(something that is hard to combine with GUI programming that requires its own eventloop)
This fundamental different approach is the root of the discussion of Blestan, I reasoned from a porting ICS perspective (windows philosophy to unix), he (and LNET with him) is more taking Unix approach to Windows.
I had exhaustive discussions with Ales on IRC about all this when he was developing lnet :-)
(though iirc at the beginning Ales mainly wanted to use epoll, and wasn't even thinking about windows compat. I got him involved with FreeBSD, and he then re-setup things more pluggable since even for *nix he had to allow multiple flavours).
In the past I also ported ICS to FPC, though I didn't maintain it.