Software Deployment

Yup. Quite true. Conflict Analysis is really MSI Database conflict analysis, not Actual Result conflict analysis. If you have a Custom Action that creates a registry key that conflicts with another app, same problem.

Another case for standardizing the way you do things.

But assuming your components are well designed and your COM registration information (registry or other) is included within the same component as the DLL/OCX itself (the keypath by definition), you most probably won't have an issue. If the GUIDs for the components are synchronised, then the component and all it's resources will only be removed once no more packages are using them.

It is therefore essential to use a repackaging tool that does an excellent job when organising resources into components. Although earlier versions possibly weren't, I believe that the latest versions of Wise Package Studio are pretty good in this respect?

Yes, I believe that the latest version of Wise (5.6) is supposed to be 'more clever' when it comes to sorting out which registry settings go with which component (and the related file). Problem is that 5.6 hasn't been out that long and we have 100s of packages where this is not the case.

I would have expected Wise conflict analysis to at least identify MSI database conflicts; OK, so they are in different tables, but it's not 'rocket science' to work out the corresponding registry settings. We've had to write our own code to identify such 'conflicts', whereas I would expect it to be part of the Wise tools!