You should add the vkEnumerateInstanceExtensionProperties and vkGetInstanceProcAddr implementation as early as possible in this first MR.
Done.
Regarding the later upcoming changes I think you should leave the swapchain wrapping for later and instead use minImageExtent from vkGetPhysicalDeviceSurfaceCapabilities2KHR (which you should also implement before vkCreateSwapchain) to indicate that 0 is unsupported. If that's not enough we may later consider wrapping swapchains but I would be more comfortable if we didn't introduce it only for this purpose if there's a simpler way.
The swapchain wrapping is used to implement (see https://gitlab.winehq.org/afrantzis/wine/-/commits/wayland-part-10/ for the tentative commits):
1. `VK_ERROR_SURFACE_LOST_KHR` and `VK_ERROR_OUT_OF_DATE_KHR` since the Wayland WSI doesn't provide these results: we are required by the spec to keep the associated `wl_surface` alive, so there can be no "surface lost" for destroyed surfaces, and there can be no "out-of-date" for resizes since the surface size is dynamic. 2. Mapping of the parent surface to ensure the client subsurface is actually visible.
For the above we need to keep the required information in a internal `wine_vk_swapchain`. That being said, we don't have to implement this through winevulkan swapchain wrapping. We could maintain a mapping between the native VkSwapchainKHR and `wine_vk_swapchain` internally in the driver and use that when needed, while passing the native VkSwapchainKHR to winevulkan unchanged. This approach adds a little bit of complexity to the driver, but it's totally reasonable (in fact the experimental branch used this). Let me know if you would prefer this route so that I can rework the upcoming part accordingly.
--
Concerning using a 0x0 extent, I went with it because I find it to be a cleaner way to communicate "nothing to draw" (e.g., when minimized) compared to 1x1. It is supported by the win32 WSI spec, and 0x0 matches the client area size in such cases, so everything is more consistent.
Some applications/frameworks detect this and skip swapchain creation/rendering. Unfortunately, I do remember coming across some applications that will do the wrong thing and actually try to create a 0x0 swapchain (prohibited by the spec), that's why I have this workaround for them to continue to work.
If we prefer a 1x1 extent instead, for consistency with WineX11, I am fine with that too. Perhaps there are also other compatibility reasons to go with 1x1?