Following that through to the blog post ([1]), it's interesting how much new API they had to add. The Windows IO API is already completion-style (as opposed to epoll, etc's readiness-style) - userspace submits an async operation to the kernel, blocks on a channel to receive its result, and the kernel enqueues the result to said channel when it's done. So I naively assumed that they'd "just" have to refit io_uring's API on top of the existing Win32 API.
uring is used for disk-IO as well, and Windows disk I/O completion has similar limitations as Linux aio does for disks, i.e. anything that actually goes into filesystem code, like allocating new blocks, creating files, anything involving metadata, still blocks. Readiness-oriented I/O of course doesn't work for disk I/O at all, because disks are always ready. And IOCPs still mean that for queuing new I/O you're going to call into the kernel at least once for each operation.
[1]: https://windows-internals.com/i-o-rings-when-one-i-o-operati...