For compatibility with old and new clients, servers will provide definitions using both v1.03 and v1.04 definitions. Even though the mechanics of accessing the definitions are different, the encodings provide the same field information except when a field is a matrix. v1.03 only provided the metadata for a 1 dimension array (length) and v1.04 provides the definition for a matrix (contains the ArrayDimensions). The value is encoded differently for each.

There is no API a client stack can use to choose the version it wants the server to use and a default choice is not defined, thus there are no rules a decoder can rely on to determine how it should decode a value other than to use the encoding NodeId that is sent with the value and use the appropriate definition. Even if the stack supports both types of encodings, this requires that the stack store both definitions in its memory. The server could switch between definitions with each value and still be in compliance with the spec.

If the stack the client is using makes any assumptions at all about which definition it should use, it may "guess wrong" and either generate decoding errors or (worse) incorrectly decode the value and assume it worked. If the client only supports one type of definition it may be different than what the server is encoding the value as, creating a compatibility issue.

Desired outcome: when both versions are supported by the server, the client can choose the version of the encoding the server shall use.

1) A server can report which style encodings it supports: v1.03, v1.04, v1.xx (future) or a combination. This can be done a number of ways, one being to create a node below the Server Capabilities folder which contains the version information.
2) a client can select which version of the encoding it wishes the server to use. This can be part of the open session request, a method call, part of a MonitoredItem request, or something else.
3) If a server does not support a client's requested encoding version, the server returns an error, An alternative is the server returns the version number that it will use. If it is different than what the client requested, the client can choose to use that version or terminate the session.

Use case (actual):
A server contains both v1.03 and v1.04 definitions. The server contains a custom type which has a field that is a matrix. The v1.04 definition includes the ArrayDimension of the matrix, while the v1.03 definition defined it as an array whose length matches the sum of the length of all dimensions. The stack only used the v1.04 definitions.

The values are transmitted using v1.03 encodings (the array dimensions are not sent). The stack tries to decode it using v1.04 definition because that was what it expected. This fails because the length of the transmitted data did not match the expected length (this is good because erroneous data is not forwarded to the application, but bad because it did not work.).

End result: client and server are incompatible.

Even if the client stack switched to using the v1.03 definition it would still be "wrong" because the client application expects a matrix (i.e. its notation for an element uses matrix notation) but the server sent an array (1D). This is a mismatch between the design-time information and the runtime value.

It is possible to convert between the two forms, but this is an additional step that must be taken and which can be done incorrectly. To do the conversion from a flat buffer (i.e. a 1D array) to a matrix the array dimensions must be known.