Also applies to the XPath 2.0 functions and operators spec.

It's not clear what happens when number() is called with no arguments, and the context item is a node whose typed value is a list containing more than one atomic value. The spec makes two conflicting statements: on the one hand, it says that number() is equivalent to number(.), in which case a type failure would occur because atomization delivers a value that does not match the required type of xs:anyAtomicType?. On the other hand, it says that if conversion of the context item to a double fails, the function returns NaN.

I think the preferred solution is that number() behaves exactly like number(.), which means there is a possibility of a type error.

Other functions whose argument defaults to the context item do not seem to have the same problem. Some of them do not atomize (for example name(), nilled()); others explicitly work on the string value of the node (normalize-space(), string-length()); while data() allows the result of atomizing to be a sequence.