Change:
A function expression is well-typed if all of the following are true: <del> If it occurs directly in a test expression, the function is declared to have a result type of "LogicalType", or (conversion applies) "NodesType". </del> <ins> If the function expression occurs as a "test-expr" in a logical expression, the function is declared to have a result type of "LogicalType", or (by conversion as per type-conv) "NodesType". If the function expression occurs directly as a "comparable" in a comparison, the function is declared to have a result type of "ValueType". </ins> <del> If it occurs directly as a "comparable" in a comparison, the function is declared to have a result type of "ValueType". </del> <ins> Otherwise (the function expression occurs as an argument in another function expression), the following rules for function arguments apply to its declared result type. </ins> <del> Otherwise, it occurs as an argument in another function expression, and the following rules for function arguments apply to its declared result type. </del> <ins> The arguments of the function expression are well-typed, as follows. </ins> <del> Each argument of the function can be used for the declared type of the corresponding declared parameter according to one of the following rules: </del> <ins> Each argument of the function can be used for the declared type of the corresponding declared parameter according to one of the following rules: </ins> <del> The argument is a function expression with declared result type that is the same as the declared type of the parameter. </del> <ins> The argument is a function expression with declared result type that is the same as the declared type of the parameter. </ins> <del> The argument is a function expression with declared result type "NodesType" and the declared type of the parameter is "LogicalType".  In this case the argument is converted to "LogicalType". </del> <ins> The argument is a function expression with declared result type "NodesType" and the declared type of the parameter is "LogicalType".  In this case the argument is converted to "LogicalType" as per type-conv. </ins> <del> The argument is a value expressed as a literal and the defined type of the parameter is "ValueType". </del> <ins> The argument is a value expressed as a literal and the declared type of the parameter is "ValueType". </ins> <del> The argument is a query and the declared type of the parameter is "NodesType". </del> <ins> The argument is a singular query and the declared type of the parameter is "ValueType".  In this case: </ins> <del> The argument is a query and the declared type of the parameter is "LogicalType".  In this case the argument is converted to "LogicalType". </del> <ins> If the query results in a nodelist consisting of a single node, the argument is the value of the node. If the query results in an empty nodelist, the argument is "Nothing". The argument is a query (including singular query) and the declared type of the parameter is "NodesType". The argument is a "logical-expr" and the declared type of the parameter is "LogicalType". Note that the last bullet item includes the case that the argument is a query (including singular query) and the declared type of the parameter is "LogicalType".  In this case the nodelist resulting from the query is interpreted as a logical-expr in the same way (extest) it would be converted to "LogicalType" as per type-conv. </ins> 2.6.4.

Discussion:
Any parameter type works with
Indeed. We could make the example more general by not talking about the parameter type there.
Or by adding a bit variety. Done.
How does this work with a parameter?
It doesn't. Example needs to be fixed. Thanks.
Ref: URL Currently is not allowed. The argument is that we've not defined as resulting in a instance (an artifact of not extending the type system to the whole expression), but I don't really see a problem with allowing it. It's pretty intuitive. I can see applications where you'd want an argument to a function to be whether a location in a path is a certain value, e.g. . An function could work this way.
If we extend the use of the type system in this way (any would be of type , possibly after implicit conversion from ), we should also roll out the other types across the spec. Then any would have type and any would have type . This fixes a bug in the current spec which I've only just noticed. The and functions are assumed to be able to take Singular Queries, but as the spec is currently written, these would need converting to using the function.
Thanks. Updating jpt to the new semantics and running it over the spec to find inconsistencies was what I wanted to do over the weekend...
I can next work on implementing this issue on Saturday.
PR attempts to implement this issue using a point solution rather than attempting to roll out the type system across the whole spec.
Approving with several suggestions that I believe will complete the remaining editorial work. (I raised some editorial nits unrelated to this PR in issue URL)