win32u is mostly ready for using syscall interface (for functions not taking HDC as an argument), but using client callbacks from syscalls will affect ability to unwind exceptions in a number of cases. On Windows, depending on kernel version, there are three different behaviors:
(1) On 32-bit Windows kernels unwinding works across client callbacks. (2) On early 64-bit Windows kernels exceptions from client callbacks are filtered and ignored. (3) On recent Windows kernels exceptions from client callbacks are treated as unhandled exceptions.
(1) is tempting because that's closest to how our pre-syscall code works. I prototyped that and I think we could make it work, but it's an additional complication to syscall interface that didn't really feel worth comparing to other options.
ntdll part of this MR implements (2). I think we would ideally use (3) instead, but it's much more risky (and syscall conversion seems risky enough on its own). Microsoft incrementally transitioned from (2) to (3) with some compatibility mitigations involved.
On top of that, some user32 calls that have win32u counterpars are still unwindable, unlike win32u variants. For example, DispatchMessageW behaves identical to NtUserDispatchMessage, except that it allow unwinding through the call, which suggests that the final call to window proc is done directly by user32, without kernel->client callback. SendMessage is also sometimes unwindable, but only when doing trivial winproc calls (but things like installing hook change that).