First of all, you cannot omit messages, else the reader might observe a MessageReceiveTimeout. There is a difference between a null value and an empty object (I know UA treats it in some cases the same). A KeepAlive message is not null but, empty. In my opinion a KeepAlive DataSetMessage in a SingleDataSetNetworkMessage with all header off, should be simply encoded as '{}'. You cannot encode it as 'null' because 'null' is not a valid JSON document.

I agree, a NetworkMessage cannot be null but has to be at least an empt JSON document when something shall be sent.
I also agree that such an empty NetworkMessage can be interpreted by the subscriber when it clearly belongs to a single DataSetMessage.
Actually this will match to the publisher configuration without the need of special exceptions:

• Something is sent at the keep alive interval to indicate that the publisher is alive.
• The NetworkMessage contains everything which was configured to be published: Nothing.

A null KeepAlive DataSetMessage message is still ambiguous if the related group has multiple writers (using delta frame messages) and I assume different subscriber implementations will handle this differently.
I recommend to describe such completely ambiguous configurations as invalid.
When a publisher sends such an ambiguous message then there is no surprise if a subscriber behaves unexpected.
Then the fault is clearly on the publisher configuration and neither on the subscriber nor on the specification to allow such ambiguity.
Especially as there are multiple ways to solve the ambiguity:

• Publish the WriterIds
• Publish only KeyFrameMessages (number of messages equals the number of Writers) with a defined DataSetMessage ordering
• Publish the single DataSetMessages to individual queues.

There are many configuration combinations that lead to ambiguous messages. And a large proportion of these are in fact not tragic and even wanted, as the recipient is a client with no knowledge of OPC UA (the whole cloud use case). Therefore, I think it would be better not to define which combinations are not useful for an OPC UA reader, but to create one or two profiles that are explicitly optimized for the two-way OPC UA communication case. If you then configure a writer/writer group that is intend to be used by a OPC UA reader, you would simply choose that profile, and you know that there are no problems for the subscriber to understand the content of the messages.

While we're at it, this is what such a profile could look like:

JsonNetworkMessageContentMask

Bit 0: NetworkMessageHeader disabled
Bit 1: DataSetMessageHeader enabled
Bit 2: SingleDataSetMessage enabled
Bit 3: PublisherId disabled
Bit 4: DataSetClassId disabled
Bit 5: ReplyTo disabled
Bit 6: WriterGroupName disabled

JsonDataSetMessageContentMask

Bit 0: DataSetWriterId disabled
Bit 1: MetaDataVersion enabled
Bit 2: SequenceNumber enabled
Bit 3: Timestamp optional
Bit 4: Status optional
Bit 5: MessageType enabled
Bit 6: DataSetWriterName disabled
Bit 7: ReversibleFieldEncoding enabled
Bit 8: PublisherId optional
Bit 9: WriterGroupName disabled
Bit 10: MinorVersion disabled

DataSetFieldContentMask configurable
KeyFrameCount configurable

The DataSetWriter's QueueName is following the recommandation of 1.05.03

I intentionally disabled the DataSetWriterId because the DataSetWriter is sending its messages to a distinct queue. I think it is better to let the broker filter instead of the reader/reader group, because this will reduce the used bandwidth. Without using the topic feature it cannot work anyway, because there is no way to decide the right recipent reader from the network message alone, due to the missing WriterGroupId. While there is a WriterGroupName you cannot configure the WriterGroupName on the Reader, only the WriterGroupId is available.