For some time I have considered that the best way to set up the namespace for Windows client components developed by our company should be simple: CompanyName.Windows.Controls. And different packages could be assembled in different library files, using appropriate naming there: CompanyName.ProductName.Controls. As you can see ProductName only appears in the assembly name, not within the namespace. This is great for end developers as they only need to reference the required assemblies and then use just one namespace to get all controls they need.
OK, but what happens if you have two public classes with the same name in different assemblies? This would generate warnings at build time and the end developers won’t be happy, althgough he or she might try to use an external alias for one of the assembly references, trying to remove the warnings.
However, there is a bigger problem in this case (assuming that you develop WPF components using XAML) because of a bug in Visual Studio (including version 2010) that preserves referencing different assemblies using extern aliases. In fact the namespace alias property is available in the Properties window for the reference, but seems to be completely disregarded if the assembly contains XAML resources. Therefore, the end develper cannot reference and use classes from both your assemblies at all (unless he or she uses an ugly MsBuild workaround)!
Conclusion: keep namimg stategy simple, as before, but whenever you add duplicate names for types inside them, make sure you add a proper, unique suffix to the namespace definition for the secondary assembly you package: CompanyName.Windows.Controls.SecondaryTopic. You can keep the primary namespace unchanged (of course, you decide which assembly and types are primary). This won’t hurt too much (the end developer just needs to add two using directives instead of one), but it will resolve a problem that is otherwise very hard, if not impossible, to solve!