Proposal (4) will only allow wined3d to interop with itself, but we can't do any better.
We can certainly do better? At least IMO forcing the implementation to use a custom mechanism just because it allows us to share with ourselves on Windows, but ultimately forbids us to interop with other implementations and APIs sounds like a dead end and a source of future problems.
It looks to me that the direction native takes is that vendors will eventually be capable of exporting D3D-compatible resources from Vulkan, NVIDIA exports its resources with a descriptor already. We should build things on the same native primitives, with only the extensions we need until they are not needed.
If the Vulkan exported resource doesn't contain the descriptor we need, which would happen on Windows but perhaps not on Wine -assuming we can implement 2) and export the descriptor in our Vulkan wrappers-, we could put them in some side channel indeed, that would make sure our D3D implementation can import its own resources.
Sure, exporting resources created from the Vulkan vendor won't work with native D3D implementation, but it will with native GL and native Vulkan. That makes things work with more APIs than 4).
Anyway, these are just stubs and it makes it possible to write tests for these functions.