Matthias asked me to provide extra details as I did bring up this issue during MQTT IOP (January's last week in 2024):

There are cases where the MQTT ClientId is forced by the Broker. For example a "Device Id" in Azure IoT Central (https://prosysopc.com/2022/07/20/iot-central-demo/). Or as part of the connection/user authentication/authorization (https://thingsboard.io/docs/mqtt-broker/user-guide/ui/mqtt-client-credentials/, the "Adding MQTT Client Credentials" part the images for step 4. Select the desired Credentials Type and configure the authentication parameters and authorization rules.).

Brokers need unique ClientId for connections, or they will typically kick the older connection away when a new connection is made with the same id.

Thus, in the Prosys OPC UA SDK for Java there is a feature that it shares the MQTT connection internally between all PubSub Connections that defined same MQTT address and credentials (clientId is part of credentials in this logic). The main use-case is if there are both MQTT-UADP and MQTT-JSON connections to the same Broker (which e.g. our https://prosysopc.com/products/opc-ua-browser/ has to do, as it's purpose is to visualize all messages of the Broker and they can be in both formats).

MQTT only allows a single last-will message (to a single topic) (https://www.hivemq.com/blog/mqtt-essentials-part-9-last-will-and-testament/), thus here we would need to chose just json or uadp for the will message. Though, I must add that regardless we can use the cyclic mode to workaround this. And the workaround also works in there would be more than a single PublisherId behind that single connection (maybe this could happen in some aggregating situations).

And I should add that the ClientId is not like always part of the authentication, just that there is the option that it may be used also in that way or that it is hard-locked some other way (basically the point is that in some cases one is limited to a single MQTT connection).

Since this may be relevant, adding an extra note that one might also wish to have multiple internal connections just for the sake of a single connection, if connected e.g. to https://docs.aws.amazon.com/general/latest/gr/iot-core.html (the 'AWS IoT Core message broker and protocol limits and quotas' section). One might be limited in a single connection throughput, but not so much in the amount of connections (here 512 Kilobytes per connection, but 500 connections on default). I would assume some large-cloud-things might scale better this way maybe. In theory here one of these connections might fail and trigger the last-will message, but maybe the other wont and would be treated like a redundant connection (not sure if we have anything in the spec for thing like "MQTT Redundancy" regarding this topic).

Probably in this case it is better to treat this Publisher effectively being separate/distributed thus just use the cyclic mode, but not sure should the spec text be clarified (as here it would still be the same system i.e. a single Publisher, but due to it's nature it should be treated as distributed one).

At that point, it'd also be worth to reconsider the sentence:

If the ClientID is not configured, the PublisherId is used as ClientID. If the PublisherId has a UInteger DataType, the UInteger value is converted to a String for the ClientID.

in https://reference.opcfoundation.org/Core/Part14/v105/docs/7.3.5.4 which also assumes that there is only one connection per PublisherId.

Discussed in the MQTT meeting today.

The shared MQTT Client connection for UADP / JSON requires to have the cyclic at least for one of the two encodings.
Need to update the text to state that the Status is related to the PubSubConnection

Table 146 – PubSub MessageTypes
Status

Changed description to:
Discovery message with the current operational status of the PubSubConnection

Table 200 – MQTT Topic level MessageType mapping
Status

Added following clarification:
If the MQTT client has multiple PubSubConnections to the same broker like for different encodings, only one PubSubConnection can register a Status message as an MQTT Will message. All other PubSubConnections must use cyclic Status messages.

Agreed to changes edited in Dallas F2F.