My current view is that anything WSI compatibility code belongs to winevulkan, as it acts as the actual vulkan driver.
I think that the claim that it acts as the actual driver is ambiguous, it all depends on how you define a driver. Yes, winevulkan.dll acts as Vulkan driver from PE Vulkan loader's point of view. Its implementation is different than conventional Vulkan ICDs as we go straight into syscalls (well, Unix calls) and the whole implementation is in kernel (well, Unix libs). On kernel side, winevulkan.so acts currently as ABI translator, it exposes client interface and passes that to the driver. Calling winevulkan.so itself a driver is not quite right. If anything winex11.so is more of a driver than winevulkan.so.
Now, winevulkan.so forwards calls to whatever it gets from win32u. In that sense, the fact that it's forwarded further to winex11.so is already abstracted from winevulkan. As far as winevulkan is concerned it already is win32u that provides the functionality.
In other words implementing Window System Integration in a module that implements window system (win32u) feels right to me.
And yes, we will want more of D3DKMT for the client interface. I imagine this will be useful for dxgi/wined3d/dwm etc, but we already have a dedicated interface for Vulkan. winevulkan.so is already on "kernel" side and already has a dedicated win32u interface, we may as well use it more.
In any case I'm not completely sure that this means that the MR would need to be reverted.
Wrapping swapchains in winevulkan.so could most likely be removed once we have win32u-side swapchains. Depending on implementation details, we may need to reintroduce some driver entry points.