Sorry about this one: it's a tiny insignificant edge case...

XDM states in section 6.3.4:

<quote>
is-idrefs
If any of the atomic values in the typed-value of the attribute is of type xs:IDREF or xs:IDREFS, or a type derived from one of those types, the is-idrefs property is true, otherwise it is false.

Note:

This rule means that a type constructed by list with an item type of xs:IDREF (or a type derived from xs:IDREF) has the is-idrefs property, whether or not the list type is named xs:IDREFS or is derived from xs:IDREFS. Because union types are allowed, it also means that an element or attribute with the is-idrefs property can contain atomic values of type xs:IDREF alongside values of other types.
</quote>

I have written a test case fn-idref-33 which uses a type

list( union( NCName[pattern='[A-Z]'], IDREF ) )

and creates two elements with this type:

<e>Q</e>

and

<e>Q some-id</e>

I believe that with the rules as written, idref('Q') matches the second element but not the first. This is because the first element does not have the is-idrefs property, because the typed value does not include an atomic value of type IDREF.

Clearly this behaviour is, to put it politely, counter-intuitive.

(For the benefit of historians, the text was introduced as a result of bug #3032)

I think there are two things we can do.

(A) we can retain this interpretation of the spec, and explain it more clearly in the (cited) Note. (The Note is anyway incorrect in talking about is-idrefs as a property of a type, when it is actually a property of a node).

(B) we can change the spec so that all elements whose type permits the type value to contain an atomic value of type IDREF have the is-idrefs property, whether or not the actual instance contains such a value. It would be an incompatible change, but it's very unlikely anyone would notice; we could claim that this is what we meant all along.