There is no equivalent to epoll on Windows. There is select (that just happens to get slower when socket's numerical id gets larger). There is also IOCP, which is an ass-backward epoll - a typical Microsoftish contraption that was supposed to be better by being more universal, but ended up being a retarded piece of disaster compared to epoll. I killed a couple of months trying to push and shape IOCP back into the BSD style API, and in the end it worked, but the guts were ugly and the process was utterly unpleasant.
So, no, the "subsystem for unix-based applications" is a no go.
If node.js could make things work on Windows using IOCP then redis could do the same. For starters, they could study the node.js code to compare the epoll version with the IOCP version in order to understand how to use IOCP,
I did say "which sounds to be the only thing redis would actually be wanting for once ported to libuv, as this patch does", a critical aside that you seem to have ignored.
It's not a wrong direction necessarily, it is just a different abstraction level. I did what I did, because of the constraints of the existing codebase. If one abstracts above the socket level, things are getting less hairy, but it also translates into substantially more per-platform code. It also makes the abstraction less flexible.
So, no, the "subsystem for unix-based applications" is a no go.