How do you plan to handle resource metadata (dimensions, usage, bind flags, etc.)? d3d11 needs to be able to retrieve that from the NT handle (and it has to be done *before* importing, since it's required to do the Vulkan import in the first place. Vulkan has no APIs to retrieve creation parameters).
I'm interested why you think D3DKMT is not worth it btw, and what you had in mind as an alternative.
The resource metadata problem is one half of it. You need either:
(1) a side channel to either set metadata on an existing resource, to be called from wined3d (there's no D3DKMT API for this). If we're going to invent such a side channel that kind of defeats the point of using the native APIs [we could use some of them, but why bother?]
(2) to use the Vulkan creation parameters to set metadata when exporting, and then translate it back to e.g. D3D11_TEXTURE3D_DESC. I'm not convinced this can be done non-destructively, and it will be a pain to write that translation.
(3) don't use Vulkan export in d3d at all, but instead create the resource on the d3d side by calling D3DKMTCreateAllocation() directly, which will be implemented on top of Vulkan image creation/allocation/etc. wined3d would then use Vulkan (or GL) to import the handle as a Vulkan resource. This matches the Windows architecture closest, but it's also a bit more complicated than anything else.
The other reason I didn't prefer these solutions when doing research is that none of them let resource sharing work on Windows. Being able to test and use wined3d on Windows is quite valuable not only for development but also for users.
(4) The solution I came up with that allows this basically involves implementing Vulkan sharing roughly as described, but d3d export would not return the Vulkan KMT handle directly, but instead wrap it in a different handle. In particular, that handle could be to a shared memory section or a regular file, which allows an unprivileged user to use it on Windows. (D3D sharing with non-d3d APIs wouldn't be possible, but there's no way to make that work.) KMT handles would be translated into a number embedded in the object name.
In order to implement D3D -> Vulkan export, Vulkan would need to check for both the "regular" and "wrapped" handles, but this should be trivial.
Needless to say, solution (4) doesn't have wined3d go through D3DKMT APIs, and at that point there's not really any point in anything else going through D3DKMT APIs, since all of that code can live on the Unix side.
Edit: fighting Markdown