Section 1.7.4 (rule 5(c)) talks of two functions "having the same signature" without saying precisely what this means.

(The exact details are not in fact that important, because while "having the same signature" is a necessary precondition for two functions to be "identical", the question still ends up being to some extent implementation-depedendant. But if we use the term, we should say what we mean by it.)

We use the same concept in XSLT 3.0 (to define constraints on overriding functions in another package), where we include the definition:

[Definition: Types S and T are considered identical for the purpose of these rules if and only if subtype(S, T) and subtype(T, S) both hold, where the subtype relation is defined in Section 2.5.6.1 The judgement subtype(A, B) XP30.]

I propose to use the same definition.

The XSLT 3.0 spec adds the notes:

Note:

One consequence of this rule is that two plain union types are considered identical if they have the same set of member types, even if the union types have different names or the ordering of the member types is different.
Consider a function that accepts an argument whose declared type is a union type with member types xs:double and xs:decimal, in that order (we might write this as union(xs:double, xs:decimal)). Using the same notation, this can be overridden by a function that declares the argument type as union(xs:decimal, xs:double). This does not affect type checking: a function call that passes the type checking rules with one signature will also pass the type checking rules with the other. It does however affect the way that the function conversion rules work: a call that passes the xs:untypedAtomic value "93.7" (or an untyped node with this as its string value) will be converted to an xs:decimal in one case and an xs:double in the other.

While this rule may appear formal, it is not as straightforward as might be supposed, because the subtype relation in XPath has a dependency on the “Type derivation OK (Simple)” relation in XML Schema, which itself appeals to a judgement as to whether the two type definitions being compared “are the same type definition”. Both XSD 1.0 and XSD 1.1 add the note “The wording of [this rule] appeals to a notion of component identity which is only incompletely defined by this version of this specification.” However, they go on to say that component identity is well defined if the components are named simple type definitions, which will always apply in this case. For named atomic types, the final result of these rules is that two atomic types are identical if and only if they have the same name.