How can I put an assembly's docs into its own namespace area?

[mikernet]

This is a bit difficult to explain so I'm not sure if this explanation will make sense or not, but I will try my best to make it clear. Please let me know if what I wrote is confusing or it's not making sense.

If you look at our docs here, there are 2 different assemblies (Singulink.UI.Navigation and Singulink.UI.Navigation.WinUI, both with <RootNamespace>Singulink.UI.Navigation</RootNamespace>) that add types to the Singulink.UI.Navigation namespace, which means the types for both are grouped into the same top-level TOC namespace section. I would like to split out the types from the Singulink.UI.Navigation.WinUI assembly into their own top-level TOC .WinUI area.

The current behavior is fine with the current release since there is only a .WinUI version of the implementations but I am planning to add other UI framework support soon, which means that Singulink.UI.Navigation.Avalonia (as a hypothetical example) would also add a bunch of types with names into the Singulink.UI.Navigation namespace that conflict with the ones added by Singulink.UI.Navigation.WinUI. These packages are mutually exclusive - you will only be targeting one particular UI framework in a project, and I'm not particularly fond of prefixing all the types in each package with a UI framework-specific prefix or putting them into different UI framework-specific namespaces. If it comes down to this then I will do it ("it" being probably putting them into UI framework-specific namespaces), but I would prefer that if someone imported the Singulink.UI.Navigation namespace, they would simply get access to the proper UI framework-specific implementation of Singulink.UI.Navigation.Navigator (for example) for the UI-specific package they are using in that project, instead of also having to import the Singulink.UI.Navigation.WinUI namespace.

What I would ideally like is if I could append .WinUI to the top-level API TOC section docfx uses for all types from the Singulink.UI.Navigation.WinUI library, so that all the types from that assembly go into their own Singulink.UI.Navigation.WinUI TOC section, instead of being grouped together with all the types from the base Singulink.UI.Navigation library and any other future UI framework-specific library that adds types to the same namespace. So, when I add a Singulink.UI.Navigation.Avalonia library, I can append .Avalonia to the namespace grouping category docfx uses for all those types as well, and those types will be in their own Singulink.UI.Navigation.Avalonia root TOC section, and there won't be 2 different Singulink.UI.Navigation.Navigator classes both in the same actual root namespace TOC section.

Just to be clear: I was planning to have both the Singulink.UI.Navigation.WinUI and Singulink.UI.Navigation.Avalonia assemblies add a bunch of types that overlap into the Singulink.UI.Navigation namespace (i.e. different versions of the Singulink.UI.Navigation.Navigator class) specific to their particular UI framework.

Does that make sense?

After writing that all out I'm considering that maybe it's just easier to put the WinUI-specific implementations in a different WinUI-specific namespace to avoid the clashes, but I still think I would prefer to just "rewrite" the top-level TOC namespace groupings for each UI-specific assembly if it was possible, to make portability between different UI frameworks more seamless. Is this possible?

Thanks in advance!