Sure, but all of these patches still have a common implicit "framework" they're introducing ABI surface to — the ntsync char device. That "framework" is axiomatic to the patches.
And that's the part that made OpenVZ unacceptable to integrate into the kernel — the axiomatic framework being introduced by the patch series. No matter how you split and refactor and document and drip-feed in the OpenVZ patches, they'd still just be a set of patches each proposing one component of an already-externally-designed higher-level feature, that can only exist if all the patches are accepted. (See the relevance?)
My understanding of how things should go in Linux kernel development, is that when submitting a single patch to LKML, 1. the motivating user-story should first be explained, and 2. the patch that follows should then be the most idiomatic way to solve that single problem within the existing architecture the Linux kernel. This will then 3. start a discussion, where any "specialization" of the design from its normative "obvious" form may be proposed, and justifications for this argued.
When submitting a patch series, each patch must go through this process independently. If there is any common framework to the patches, it can only be because the "obvious way" (by the consensus of all participants) to solve patch 2's user-story, with patch 1 already in place in a dev branch, is to refactor the logic of patch 1 and patch 2 together.
In other words, it should be up to the core kernel maintainers — not the contributor — to propose an in-kernel architecture like "this set of operations introduced over the last few development patch series, would make a lot of sense to expose as messages passed into a single character device." And such an architecture should be proposed because it's what's best for the kernel, rather than because having it that way would make the contributor's life easier in implementing their library.
(The only exception to this being if the aim is to support direct interoperation with some existing portable software, by exposing a syscall or device or filesystem that other platforms already have, and that existing software already depends upon on these other platforms. Which doesn't apply here — NT itself doesn't have an ntsync device!)
I would expect, if this process were followed for NT's sync primitives, that:
• some of the resulting changes would introduce ioctls;
• some of the resulting changes would add flags for the io_uring or epoll syscall families;
• and some of the resulting changes — for the legacy NT sync-primitive objects specifically — would probably become their own syscalls (probably in such a way that they only exist with a certain kernel module loaded, so that the attack surface they represent can be disabled in hardened systems.)
These changes would likely all solve the problems as stated (i.e. making it possible to execute NT software that uses sync-object X, with only a userland translation library between the kernel and the software, no RPC daemon needed) ... but these changes likely wouldn't solve the problems in the most efficient way for WINE. Not if there's any other uses — in greenfield Linux software, in virtualization of other OSes, in accelerated kernel-mode hypervision, etc — for exposing such primitives.
And also, obviously, these primitives would all end up fairly different from one-another, and from what NT expects — and so WINE would still need a fairly complex translation layer to target these syscalls. Just like it does today. Just, one without inefficiant and apparently-untenable userland arbitration.