The LoraWAN specification reserves the upper 7 bits of the DevAddr as the NwkID which is intended to 'remedy roaming issues' but doesn't fully define how to resolve roaming. This means a network server should choose which network they belong to an assign device id's accordingly. This is easier with OTAA...
The Lora Star topology makes this conceptually fairly straightforward.
In the simplest terms you want all gateway traffic to reach all network servers.
One solution is for all gateways to have a list of all known network servers and run the polypacket forwarder.
However this is not scaleable so what you want is to have a cloud polypacket forwarder as a proxy. I developed something like this when swiching traffic between different gateways while creating testing tools for my virtualbreadboard.io network server
This will still mean all network servers receive all traffic so this is also not practical so this is where the LoraWAN NwkID concept should be used to partiton the groups of network severs into logical groups and filter the traffic ending up at the network servers to only that traffic belonging to that NwkID.
More than one network server might belong to a NwkID, it's just used as a traffic filter for cloud based polypacket forwarders. Be they called routers, proxies, brokers or whatever.
I don't think there is global governance for NwkID's but that's the intention I believe. Also there doesn't have to be. There can be separate networks with their own NwkID's that never interact also. It's defined by the list of network servers belonging to each NwkID.
Individual gateway operators can choose to participate in which ever networks they wish by selecting which forwarder they add to their polypacket forwarder list - or it could be just directly to their own network server for a private network.
I think MQTT etc exist outside of this construction and are the domain of individual network/application services. Although it could be practical to implement a could based polypacket forwarder in MQTT if the network server had an MQTT listener as an additional injestion point to UDP.
If there is interest I will make a service available to demonstrate the mechanism.