RE: [XPath 2.0] XPath 1.0 Compatibility Mode doesn't cover fn:number

Don Chamberlin wrote: 
 
 The revised rules for function argument conversion in XPath 1.0
compatibility mode are as follows: 

If XPath 1.0 compatibility mode is true and the argument is not of the
expected type, then the following conversions are applied sequentially to
the argument value V: 
1. If the expected type calls for a single item or optional single item
(examples: xs:string, xs:string?, xdt:untypedAtomic, xdt:untypedAtomic?,
node(), node()?, item(), item()?), then the value V is effectively replaced
by V[1]. 
 
 
It's also worth pointing out section 2.5.3 which contains the statement:
Similarly, in evaluating an expression, an implementation is not required to
search for data whose only possible effect on the result would be to raise
an error 
 
My reading of this statement is that when 1.0 compatibility mode is off,
supplying a sequence of more than one item to a function that expects a
singleton is an error that the implementation is not required to detect. For
example, if you write string(//TITLE), the implementation is allowed to give
you the string value of the first TITLE in the document, without searching
the rest of the document to see if there are any more, as the only effect of
this search on the result would be to raise an error. So the XPath 1.0
first-item rule is still there, albeit in a deprecated kind of way. I
mention this because a number of people have expressed concerns about the
performance implications of dropping the first-item rule.
 
Michael Kay (speaking personally)