It was already mentioned but, at the cost of being annoying, let me reiterate: d3dx* DLLs can't directly use wined3d data types or APIs. They have to go through the respective d3d* client library functions.
I suspect that code sharing between d3dx* versions will eventually happen in a somewhat different fashion and trying to build the "final solution" from the ground up is going to be hard. Porting the various pieces of code to d3d[x]11 as necessary, even at the cost of "duplication" in the short term, is probably a better plan.
I somewhat doubt it. It wasn't too hard to use the d3dx9 parts for d3dx11, and it shouldn't be too hard to make it a good generic version. It would make both d3dx9 and d3dx11 simpler, while providing modular abstraction. Just loading a texture or texture information is something that can be standalone.
I'm open to change of course, but I'd like to understand the reason behind it. It's not linked to wined3d anymore, only uses the intermediate imageformat. Since a generic imageloader can't rely on DX9 types nor on DX11 and since I didn't want to reinvent the wheel, I just used the implemenation at hand: wined3dformat.