While I agree that wrapping swapchains outside drivers and handling more there is the right direction, I think this deserves some consideration where to do that. The alternative would be doing that in win32u. Giving win32u the ability to manage swapchains seems interesting for things like a compositor in the future, where win32u may want to interfere more (or even take a full driver-independent control in cases like child window rendering) in swapchains. It also gives swapchains access to win32u internals.
If we'd indeed want to do that, then another layer of wrapping in winevulkan becomes redundant. One way to implement it (not the only one and I'm not saying it's the best one) would be to intercept driver `vulkan_functions` in `__wine_get_vulkan_driver` and chain some of those calls. If we wanted something like that, we'd need to revert a good chunk of this MR, so I'd be interested in your opinion on above.