That's... not what I saw when testing? The runtime data for shared resources exported from Vulkan was always empty.
Assuming our understanding of how the driver stack works internally is correct, drivers _cannot_ do this
It's not empty and they do, see the results https://testbot.winehq.org/JobDetails.pl?Key=148242 of [0001-vulkan-tests-d3dkmt.patch](/uploads/b4f25dc72a4c8a4a473327a42de07d23/0001-vulkan-tests-d3dkmt.patch).
It crashes at the end is because importing it into D3D doesn't work but the descriptor is filled nonetheless. It's missing width and height so perhaps that's just why it fails, or perhaps it's missing more information, I don't know.
It doesn't forbid us to interop on Wine; we can check whether we have a "wrapped" or "unwrapped" handle and deal with either.
It forbids to interop with native APIs, which is one important use case for these shared handles. Among all the solutions, 4) is the only one where exporting from WineD3D and importing into GL/VK wouldn't work on Windows.
How? We can't inject metadata into an arbitrary NT handle.
You could setup a shared memory section used by WineD3D instances, where you'd store a handle -> descriptor mapping, which is probably what you meant with side-channel in 1).