Yes, I also think that some things will need to be moved to win32u, but it's not completely clear how this would be done yet. In any case I'm not completely sure that this means that the MR would need to be reverted.
My current view is that anything WSI compatibility code belongs to winevulkan, as it acts as the actual vulkan driver. Code in win32u/user drivers would be more about integration with the host. With that in mind, surface extents fixups better belong to winevulkan than in win32u or the user drivers.
For future development, and for instance to implement this compositing idea, I'm not completely sure that this should be done on the vulkan level directly, and maybe instead it should use a different one (say D3DKMT*) that would work with other APIs too, and that would be what win32u would expose and implement.
Alternatively, maybe we could expose winevulkan wrapper structures in wine/gdi_driver.h, making them usable for win32u / user drivers and avoid having to wrap them again.