trusted_authorities: is a mismatch advisory or a hard exclusion?

Section 6.1 makes the matching condition advisory:

Every Credential returned by the Wallet SHOULD match at least one of the conditions present in the corresponding trusted_authorities array if present.

Section 6.4.2, Selecting Credentials, states the consequence in keywords:

Credentials not matching the respective constraints expressed within credentials MUST NOT be returned, i.e., they are treated as if they would not exist in the Wallet.

trusted_authorities is a property of a credentials entry, and Section 5 makes that evaluation mandatory: "Wallet implementations MUST process the DCQL query and select candidate Credential(s) using the evaluation process described in Section 6.4". So an advisory condition is read through a mandatory prohibition, and the End-User is told they hold nothing.

For the analogous restriction the specification wrote an explicit carve-out. Section 6.4.1, Selecting Claims, concedes that "Implementing this restriction may not be possible in all cases" and then bounds what a Verifier may conclude:

Verifiers MUST treat restrictions expressed using values as a best-effort way to improve user privacy, but MUST NOT rely on it for security checks.

I could not find an equivalent for trusted_authorities.

The second case is a Wallet that cannot evaluate the condition at all. type is REQUIRED, and "Types defined by this specification are listed below", and I could not find text saying what a Wallet does with a type value it does not recognize. Section 6.1.1 defines matching descriptively, as a Credential matching one of the provided values in one of the provided types, so a Wallet that cannot interpret the type cannot determine a match either way, and Section 6.4.2 then treats that as not matching.

Both directions of change are already requested. #494 asks for a new type value. #686 asks instead to widen the existing etsi_tl type to cover a second ETSI standard, explicitly to avoid a breaking change, which would mean a Wallet can recognize the type string and still not handle the list that arrives under it.

Is a mismatch a non-match subject to the same best-effort treatment as values, or a hard exclusion? And which of the two applies when the Wallet cannot evaluate the condition?

Read Sections 5, 6.1, 6.1.1, 6.4.1, and 6.4.2, then compare the related proposals in #494 and #686. Determine whether trusted_authorities mismatches and unevaluable types receive best-effort or mandatory-exclusion treatment, and document consistent normative wording for both cases.