The description of the static context in XPath 3.1 says:

<quote>
[Definition: Statically known function signatures. This is a mapping from (expanded QName, arity) to function signatureDM31. ] The entries in this mapping define the set of statically known functions — those functions that are available to be called from a static function call, or referenced from a named function reference. Each such function is uniquely identified by its expanded QName and arity (number of parameters). Given a statically known function's expanded QName and arity, this component supplies the function's signatureDM31, which specifies various static properties of the function, including types.
</quote>

Most of the time, the spec is careful to make clear that it is only the function signatures that are present in the static context -- not actual function implementations.

For XSLT 3.0 packages, this is essential. For example, XSLT 3.0 makes it possible to reference an abstract function whose implementation will be supplied later in a different package. The function signature is known statically, but the implementation is not.

The only place where the XPath 3.1 spec slips up on this distinction is in fact in the paragraph cited above, which is the only place that talks of "statically known functions" rather than statically known function signatures.

Suggested rewording:

<quote>
[Definition: Statically known function signatures. This is a mapping from (expanded QName, arity) to function signatureDM31. ] The entries in this mapping define the signatures of the functions that are available to be called from a static function call, or referenced from a named function reference. Each such function signature is uniquely identified by its expanded QName and arity (number of parameters). The function signatureDM31 defines various static properties of the function, including types.
</quote>