We encountered different interpretations about what the DefaultEncodingId means in the context of different encodings and what that means for storing the information and for communication.
It affects the DataTypeDefinition attribute of DataType nodes and the DataSetMetaData for PubSub (Binary and JSON).
The storing includes storing and reading the value to/from a nodeset.

Part 3 Chapter 8.48 Structure Definition
"(...)The default depends on the message encoding, Default Binary for UA Binary encoding, Default JSON for JSON encoding and Default XML for XML encoding. (...)"

Interpretation 1: The structure and its value exists only once on a source OPC UA application (Server or PubSub Publisher)
Pro: It is always clear which value to use for storing or for any communication.
Applications can fill the DefaultEncodingId on different places for intended use cases.
Contra: The EncodingId is only usable for one encoding type, other supported encodingIds must be retrieved in a different way (if possible at all).
Receivers are not able to know to which encoding type this EncodingId belongs to.
For example a PubSub publisher is able to publish Binary UADP data and JSON MQTT data and stores the BinaryEncodingIds in the StructureDefinitions.
The StructureDefinitions are reported in MQTT MetaData.
A subscriber which received the meta data is still not able to decode a data type for the not recognized JSON encodingId.
-> The reported DefaultEncodingId may be unknown to which encoding type it belongs to and may be useless.
-> For this interpretation it would be good to know to which encoding type this ID belongs to.

Interpretation 2: The structure has to be filled with the matching EncodingId whenever it is transported, using the encoding type which currently transports this structure to the receiver.
Pro: The receiver always gets an EncodingId which matches to its current encoding type and thus is able to use it for the current encoding type.
Contra: If a receiver (Client or Subscriber) is interested in the EncodingId for a different encoding type, then the reported EncodingId is not usable.
For example there is a combined Server with Publisher and a combined Client with Subscriber.
The client uses the ReadService using Binary encoding to read the DataSet configuration from the PublishedDataSet->DataSetMetaData property.
It will only get the BinaryEncodingId (as the ReadService used binary encoding) but not the DefaultJson EncodingId.
To get the DefaultJSON encodingId the client needs to browse the DataType nodes on the server to find the DefaultJson EncodingId.
-> The reported DefaultEncodingId is known where it belongs to but may still not be usable (as it belongs to a different encoding).

Which is the correct interpretation?

Note: For Interpretation 1 for a publisher only application:
When a PublishedDataSet shall be used by two DataSetWriters for different encoding types, then the PublishedDataSet is not able to report usable MetaData information (via DataSetMetaData messages) for both encoding types.
It requires to duplicate the complete PublishedDataSet and configure each for one encoding type.