This refers to any case in PubSub where a named PubSub component has a non-constant browse name. Just as an example, take the PubSubConnectionType, which has HasComponent references to its writer groups and reader groups. The BrowseName of these depends on the configuration

In my use case, I am writing a library that is a subscriber. I want to be able to specify the necessary information physically (such as with URL, publisherId, writer group Id, dataset writer ID etc.), or logically: By referring to a PubSub configuration, and using names (name of connection, name of writer group, name of the dataset writer). In the latter case, the logical information is first resolved into a physical one by the library.

For the resolution process, I want the configuration reside either in a binary file, or "live" in OPC UA server with the PubSub configuration model in it, and it should look the same to the developer.

When referring to PubSub components that are in the configuration file, I need just strings. There are no namespaces with them.
However, when referring to PubSub components within an address space, I also need a namespace.
I originally (incorrectly) assumed that these browse names will be in namespace 0. But as it turns out, each server puts them into its own namespace, as they see fit.

This means that with, having just a string, I cannot use translation of browse paths. A solution would be to have the developer using my library specify the names by "full" browse names, but that is ugly, and does not then fit with the case when the configuration is loaded from the file.

In essence, any programmatic tool that wants to deal with PubSub configuration and look up components by name will confront this issue.

Another use case where this disparity (between configuration in a file and in the server) causes problem is when a configuration is exported and then imported again. There is no guarantee that this roundtrip will recreate the same configuration, because the PubSub components may end up in different namespaces.

Possible solutions:
1) Somehow also store the namespaces of the PubSub component names in the configuration data/file. I do not like this.
2) Specify that these BrowseNames will use namespace 0. This probably won't go through, but I wanted to mention it. No conflict will arise because they are just BrowseNames, not NodeIds, but I understand that it is against the idea o having the standard namespace reserved for standard entities only.
3) We will specify a URL, different from the standard namespace, for a single namespace where all these BrowseNames for PubSub component will live. This is my preferred solution.

Disadvantage of solutions 2) and 3) is that they complicate merging/aggregation, but I do not think this a show stopper.