As far as I can see the resource descriptor lives in the pPrivateRuntimeData buffer, which can be set on creation, or queried/opened later. The buffer structure isn't documented and apparently has changed a bit across windows versions but looking at it it seems to be simply the texture descriptor with some header (the header has grown from W8 to W11, the descriptor stayed the same), it should be possible to test and reverse it to be compatible.
The instability across Windows versions is one problem, yes. I think the bigger problem is probably the rest of the driver-private data, which, as you mention, is driver-specific and unstable, not just in theory but in practice.
There may very well be other hidden things that the driver does. Trying to use d3dkmt functions directly from wined3d and on Windows is essentially trying to replace exactly one half of the GPU driver, and I don't think it can be expected to work.
Proposal (4) will only allow wined3d to interop with itself, but we can't do any better.
_(I haven't confirmed it but I suspect that either you cannot import Vulkan-created images into D3D unless the Vulkan driver adds that descriptor, or they use some driver-specific callbacks to parse the driver data which we probably can't do, and driver data seems much more unstable.)_
I have confirmed it—word from a Microsoft Direct3D developer is you cannot export from Vulkan and import into Direct3D on Windows. The capability exists in the Vulkan API, but that path simply doesn't work.
Then, for wined3d running on GL on Windows, the problem is even bigger, as there's simply no way to export GL underlying resources. So, if we want wined3d/GL shared resources to work on Windows, we'll need to create the D3DKMT resource upfront and import it (instead of using a Wine-specific extension for export).
Yes, there's no way to make export work when using the GL backend. It's unfortunate but there's nothing we can do about it.