I haven't really thought about it much, but basically my idea was simply to do it the same way Windows does it, as much as possible. So pretty much 2) or 3) I guess.
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.
However, on Windows, while resources exported from D3D have the descriptors set, images exported Vulkan drivers don't, and instead seem to use pPrivateDriverData buffer (well it's also a bit vendor dependent).
_(I haven't confirmed it but I suspect that either you cannot import Vulkan-created images into D3D unless the Vulkan driver implements it, 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.)_
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).
Considering these issues, it seems to me that 3) is the only viable option if we want the widest compatibility with Windows, as 4) will only make wined3d work with itself, and not if you want to share resources with Vulkan, GL, DXVK, or native D3D.
We can anyway do 2) as an intermediate step, or if we decide that wined3d over GL can live without this feature on Windows, and assuming Vulkan driver vendors might make their resources D3D compatible at some point, like Wine would.