In the first place it's conceptual, wined3d is Wine's equivalent to the D3D driver interface, it shouldn't be concerned with high-level utility functionality like D3DX. Second, and related, as Michael mentioned, Microsoft's d3dx9 doesn't depend directly on the D3D driver interface. You can use Microsoft's d3dx9 on Wine, and ideally you should be able to use a Win32 build of Wine's d3dx9 as a drop-in replacement on Windows, without additional dependencies.
Ah well I see, makes sense.
It's largely up to Matteo and Alexandre, but I think there are a few options. We could for example use a single PARENTSRC for d3dx9/10/11. That would still require some thought, since while I'd expect many things to be similar or the same between d3dx9/10/11, there are also a considerable number of differences. Another option could be a static library like libwpp or libwine_port, although that's not a popular option. Maybe it's warranted for d3dx. Maybe there are other options as well.
Well, there are differences between d3dx9 and d3dx11, but it's possible to deduplicate at least a part of the code. I'm trying to get it done with texture loading, but I'd need to know where to put it. At least parsing the DDS or using WIC to load images, and the converter functions are nearly exactly the same. The only other option I see would be to not care about extracting these code parts and making a full blown copy in d3dx11 like I have it on my temporary branch. It works, but to me it seems like a bad approach.