Original text:
subsections, JSONPath defines an extension point that can be used to add filter expression functionality: "Function Extensions". <del> This section defines the extension point as well as four function </del>  extensions that use this extension point.  While these mechanisms are designed to use the extension point, they are an integral part of the JSONPath specification and are expected to be implemented like any implementation level only -- they do not influence the result of the evaluation.) <del> A function argument is a "filter-query" or a "comparable". According to filter-selector, a "function-expr" is valid as a "filter-query" or a "comparable". </del> Any function expressions in a query must be well-formed (by conforming to the above ABNF) and well-typed, otherwise the JSONPath implementation MUST raise an error (see synsem-overview).  To define 2.6.2. <del> The following implicit type conversion may occur: </del>  <del> Where an instance of "NodesType" needs to be converted to a "LogicalType", the conversion proceeds as follows: </del>  <del> If the nodelist contains one or more nodes, the conversion result is "LogicalTrue". </del>  <del> If the nodelist is empty, the conversion result is "LogicalFalse". Given an expression with a declared type of "NodesType", a "ValueType" can be obtained using a function such as "value()" (see value). </del>  The well-typedness of function expressions can now be defined in terms of this type system. 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>  <del> If it occurs directly as a "comparable" in a comparison, the function is declared to have a result type of "ValueType". </del>  <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>  <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>  <del> The argument is a function expression with declared result type that is the same as the declared type of the parameter. </del>  <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>  <del> The argument is a value expressed as a literal and the defined type of the parameter is "ValueType". </del>  <del> The argument is a query and the declared type of the parameter is "NodesType". </del>  <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>  2.6.4. filter expression: Its only argument is an instance of "ValueType" (possibly taken from <del> a singular query as in the example above).  The result also is an </del>  instance of "ValueType": an unsigned integer or "Nothing". If the argument value is a string, the result is the number of entirety of, see search below) a given string matches a given regular expression, which is in I-D.draft-ietf-jsonpath-iregexp form. <del> Its arguments are instances of "ValueType".  If the first argument is not a string or the second argument is not a string conforming to I- D.draft-ietf-jsonpath-iregexp, the result is "LogicalFalse". Otherwise, the string that is the first argument is matched against the iregexp contained in the string that is the second argument; the result is "LogicalTrue" if the string matches the iregexp and "LogicalFalse" otherwise. </del>  2.6.7. given string contains a substring that matches a given regular expression, which is in I-D.draft-ietf-jsonpath-iregexp form. <del> Its arguments are instances of "ValueType".  If the first argument is not a string or the second argument is not a string conforming to I- D.draft-ietf-jsonpath-iregexp, the result is "LogicalFalse". Otherwise, the string that is the first argument is searched for at least one substring that matches the iregexp contained in the string that is the second argument; the result is "LogicalTrue" if such a substring exists and "LogicalFalse" otherwise. </del>  2.6.8. processing in the filter expression: Its only argument is an instance of "NodesType" (possibly taken from <del> a "filter-query" as in the example above).  The result is an instance of "ValueType". </del>  If the argument contains a single node, the result is the value of the node. If the argument is "Nothing" or contains multiple nodes, the result is "Nothing".  2.6.9. 2.7.

Reviewer comments:
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)

Revised text:
subsections, JSONPath defines an extension point that can be used to add filter expression functionality: "Function Extensions".  <ins> This section defines the extension point as well as some function </ins> extensions that use this extension point.  While these mechanisms are designed to use the extension point, they are an integral part of the JSONPath specification and are expected to be implemented like any implementation level only -- they do not influence the result of the evaluation.)  Any function expressions in a query must be well-formed (by conforming to the above ABNF) and well-typed, otherwise the JSONPath implementation MUST raise an error (see synsem-overview).  To define 2.6.2.  <ins> Just as queries can be used in logical expressions by testing for the existence of at least one node (extest), a function expression of declared type "NodesType" can be used as a function argument for a parameter of declared type "LogicalType", with the equivalent conversion rule: </ins>  <ins> If the nodelist contains one or more nodes, the conversion result is "LogicalTrue". </ins>  <ins> If the nodelist is empty, the conversion result is "LogicalFalse". </ins>  <ins> Extraction of a value from a nodelist can be performed in several ways, so an implicit conversion from "NodesType" to "ValueType" may be surprising and has therefore not been defined.  A function expression with a declared type of "NodesType" can indirectly be used as an argument for a parameter of declared type "ValueType" by wrapping the expression in a call to a function extension such as "value" (see value). </ins> The well-typedness of function expressions can now be defined in terms of this type system. A function expression is well-typed if all of the following are true:  <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>  <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>  <ins> The arguments of the function expression are well-typed, as follows. </ins>  <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>  <ins> The argument is a function expression with declared result type that is the same as the declared type of the parameter. </ins>  <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>  <ins> The argument is a value expressed as a literal and the declared type of the parameter is "ValueType". </ins>  <ins> The argument is a singular query and the declared type of the parameter is "ValueType".  In this case: </ins>  <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. filter expression: Its only argument is an instance of "ValueType" (possibly taken from  <ins> a singular query, as in the example above).  The result also is an </ins> instance of "ValueType": an unsigned integer or "Nothing". If the argument value is a string, the result is the number of entirety of, see search below) a given string matches a given regular expression, which is in I-D.draft-ietf-jsonpath-iregexp form.  <ins> Its arguments are instances of "ValueType" (possibly taken from a singular query, as for the first argument in the example above).  If the first argument is not a string or the second argument is not a string conforming to I-D.draft-ietf-jsonpath-iregexp, the result is "LogicalFalse".  Otherwise, the string that is the first argument is matched against the iregexp contained in the string that is the second argument; the result is "LogicalTrue" if the string matches the iregexp and "LogicalFalse" otherwise. </ins> 2.6.7. given string contains a substring that matches a given regular expression, which is in I-D.draft-ietf-jsonpath-iregexp form.  <ins> Its arguments are instances of "ValueType" (possibly taken from a singular query, as for the first argument in the example above).  If the first argument is not a string or the second argument is not a string conforming to I-D.draft-ietf-jsonpath-iregexp, the result is "LogicalFalse".  Otherwise, the string that is the first argument is searched for at least one substring that matches the iregexp contained in the string that is the second argument; the result is "LogicalTrue" if such a substring exists and "LogicalFalse" otherwise. </ins> 2.6.8. processing in the filter expression: Its only argument is an instance of "NodesType" (possibly taken from  <ins> a "filter-query", as in the example above).  The result is an instance of "ValueType". </ins> If the argument contains a single node, the result is the value of the node. If the argument is "Nothing" or contains multiple nodes, the result is "Nothing". <ins> Note: a Singular Query may be used anywhere where a ValueType is expected, so there is no need to use the "value" function extension with a Singular Query. </ins> 2.6.9. 2.7.