It's a shame you feel that way. I understand there is technical limitation due to the blocking nature of one of the subcomponents, but if Microsoft (or some other organization) solved that issue, it sounds like you'd continue mixing open source politics with your product development decisions which I would argue isn't conducive to more widespread adoption of the software or the health the software's ecosystem.
It does of course make sense as I assume you're developing this because you want to, and not as part of a company's bottom line, which means really you can do whatever you like. No sense developing something if you're not enjoying the process. If however you ever take this to a level where you have a financial incentive in furthering the software's adoption, I'd urge you to do whatever it takes to get an official Windows port in there, which would mean looking at any aspects of the implementation that cause issues on that platform, and doing what you can do to overcome them.
Yes indeed, astonishingly, people do thing for reasons other than money.
However, even if this was a commercial project, this would still be the correct decision. Innovating new features, polishing and making Redis even better is exactly what @antirez should be doing.
Make an awesome product. Not a half-assed one that runs on every device / os / mobile under the sun. I've seen more than one project dissolve in mediocrity under the pressure of trying to do that.
At times, antirez does appear to be a bit bone-headed. In the early days of redis (pre-1.0 I think) I (among several others) had sent him patches to incorporate unix domain socket support into redis server/client. Not to mention, the patches were summarily rejected by Salvatore. Google "unix socket redis" and you'll find numerous patches developed by several authors for redis 1.x - none of them made it into the official release.
Curiously, I noticed unix sockets had been officially added in version 2.2.0.
It does of course make sense as I assume you're developing this because you want to, and not as part of a company's bottom line, which means really you can do whatever you like. No sense developing something if you're not enjoying the process. If however you ever take this to a level where you have a financial incentive in furthering the software's adoption, I'd urge you to do whatever it takes to get an official Windows port in there, which would mean looking at any aspects of the implementation that cause issues on that platform, and doing what you can do to overcome them.