There is no breaking change, only a clarification.

The following sentence for legacy token secret format was always in the spec:
"The password secret exchanged with this format shall not exceed 64 bytes."

One of the reasons for introducing the EncryptedSecret was an issue with passwords exceeding the size of 65 bytes.

The additional clarifications just define when to use the legacy and when the EncryptedSecret format and how a server can check for the difference.

Okay, I see.
But my main concern was when a server implements the suggested
algorithm, there is a certain likelihood that the received legacy format's
first few bytes can be parsed as TypeId, EncodingMask and Length,
making the user authentication failed.

We discussed in Dallas F2F. The non-encrypted case requires a specific byte to be zero followed by a length that must match of the blob. This makes it extremely unlikely that these two payload forms will be confused. In the worst case both formats can be assumed and tried.

Agreed to no-fix.

Agreed to no-fix in Dallas F2F.

I got a further request for clarification.

It is very likely that the TypeId resolves to a valid NodeId but not a NodeId for the two supported encryption types.

byte to be zero followed by a length that must match of the blob

From the wording of the spec I only read there must be a length.
Maybe that the length must match something specific should be clarified as well.

Well, am I right that the 64-byte password limit has the purpose to avoid
encoding multiple RSA blocks, which would in worst case encode the
secret and the nonce in different RSA blocks?

So we know that a ligitimate Legacy Secret has exactly the length
of one RSA block. While an RsaEncrytped Secret must always be
longer that one RSA block, because it contains one block + extra stuff?

Wouldn't that allow a bullet-proof detection of the encryption format?

Updated text to:
The EncryptedSecret format starts with a TypeId, EncodingMask and Length. These values allow a Server to determine how to handle the secret. If the TypeId does not resolve to one of the defined EncryptedSecret format DataTypes and a USERNAME UserIdentityToken has been provided then the Server may attempt to handle the secret using the legacy token secret format.

Agreed to changes in web meeting.