Shared swapchain behaviour is unclear

The behaviour of `vkCreateSharedSwapchainsKHR` seems very unclear to me.

Is the intention that a single set of presentable images will be created and shared between all the swapchains? i.e. calling `vkGetSwapchainImagesKHR` on each of the swapchains will return an identical list of images.

I think it must be, because if they're different there's no way to submit a single image to multiple swapchains, given that `vkQueuePresentKHR` takes image indexes rather than `VkImage` handles. But as far as I can see, the specification doesn't actually define that (or even imply it clearly).

> After destroying one or more of the swapchains, the remaining swapchains and the presentable images can continue to be used.

That contradicts the definition of `vkDestroySwapchainKHR`, which clearly says "`swapchain` and all associated `VkImage` handles are destroyed, and must not be acquired or used any more by the application". The specification needs to be self-consistent.

Also this seems to say that the presentable images can continue to be used after _all_ the swapchains are destroyed, which can't be right - presumably they're meant to be refcounted so they can still be used until the last of the set of swapchains is destroyed but no longer than that.

> Images presented to multiple swapchains must be re-acquired from all of them before transitioning away from `VK_IMAGE_LAYOUT_PRESENT_SRC_KHR`.

Since `vkAcquireNextImageKHR` provides no guarantees on the order it returns images in, this seems an almost impossible feature to use - you might submit images A and B to swapchain 1, then submit A and B to swapchain 2, then acquire A from one and B from the other, and now you don't have any single image you can re-submit to both swapchains, and if you try to acquire any more images then you might block, so there's no good way to proceed. I think the acquire order of shared swapchains needs to be much more tighly defined for it to be usable.