I think the general approach is good.
The way you handle the built in implementation seems odd to me. I think setting the registry key to make the freedesktop.org version as the default would be good enough.
If we don't have built-in trash etc. objects then when we add a new object we will require all the implementations have it, with no backward compatibility. However this should not be a big problem as the freedesktop.org implementation can be kept up-to-date with shell32 and the other implementation can fallback to it if they don't support a specific object.
I'm not convinced we need IWineShellIntegration. I think it would be cleaner to directly create an IWineTrash object.
If we integrate more closely with the desktop environments we may need to have one central object that will know that e.g. KDE 3.4 uses the freedesktop.org Trash but KDE 3.3 has it's own Trash implementation. If we read the Trash CLSID from the registry such an implementation would require creating proxy classes or hacks in the class factory. Also by storing only one CLSID we don't have a problem which implementation to use if a new kind of objects is introduced.
Of course when we use COM aggregation instead of a factory pattern we will have all the interfaces visible under one CLSID so we will be able to construct a IWineTrash directly with the main object hidden behind the scene.
Mikolaj Zalewski