Yes, so that's what I am saying and we need to use one wl_surface for each VkSurfaceKHR the application may allocate.
Yeah, but in the case of windows the native surface would be an HWND, so what wine does would not be legal according to the vulkan spec. However, clearly Windows behaves differently, so that overrides anything the vulkan spec can say.
it seems to me that this is all a bad design of the protocol, and that it _needs_ to be redesigned.
It might be, it might not be. Either way, I doubt one client can convince them to change a protocol that has been there for ~10 years. Especially considering XWayland also is suboptimal to start with (and nowhere in the vulkan spec does it say that suboptimal to begin with is illegal, because you aren't supposed to be creating a new VkSurface for every suboptimal in the first place) -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11342#note_145146