Change:
(2) The arguments of the function expression are well typed when each argument of the function can be used for the declared type of the <del> corresponding parameter, according to one of the following conditions depending on the way the argument is supplied: </del> <ins> corresponding parameter, according to one of the following conditions: When the argument is a function expression with declared result type the same as the declared type of the parameter. When the declared type of the parameter is "LogicalType" and the argument is one of the following: A function expression with declared result type "NodesType". In this case the argument is converted to LogicalType as per type-conv. A "logical-expr" that is not a function expression. When the declared type of the parameter is "NodesType" and the argument is a query (which includes singular query). When the declared type of the parameter is "ValueType" and the argument is one of the following: A value expressed as a literal. A singular query.  In this case: 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. </ins> 2.4.4.

Discussion:
Fixes URL
You're welcome. The issue needed a bit of "show, don't tell". I currently agree, but I'd like to let this PR go "cold" for a while and then compare how this section reads relative to the main branch. Meanwhile, others may like to give their opinions.
I now ran the tests (and updated a few details with changing external tests)
The organization of the expansion of point 2 in "Well-Typedness of Function Expressions" can be improved. Currently, it's grouped by the kind of argument, but it's much easier to consume if you group by function parameter type. (Also, I think we're missing some cases.) I'm going to put it in a table so it's a bit easier to see. The above answers the question I don't think that's going to be a very common question JSON Path authors will have. I think the more common question will be To that end, we need to invert the grouping by using parameter type as the key. Doing this, we get This is a lot easier to consume and mentally digest. It also better serves as a reference for JSON Path authors. (We lose the "function type matches parameter type" thing, but I don't think we need to explicitly say that.)
Questions: (1) A is defined in the draft as a list of location-value pairs. Is there a distinction between and ? (2) If a function has a parameter that accepts arguments of , does it receive a list of location-value pairs?
Abstractly, yes. A nodelist is an instance (or member) of . Yes.
NAME thanks. Are the following statements correct? The JSONPath query in its entirety always evaluates to a nodelist (a list of location-value pairs) Within a filter, a JSONPath query evaluates to either a value of type or a nodelist of type . If the query satisfies the requirements of a Singular Query, it evaluates to a value of type , otherwise it evaluates to a nodelist of type .
Yes A query always evaluates to a nodelist (). In the context of a filter expression, if it's a singular query, the resulting nodelist can be implicitly converted to a value () by extracting the single node's value (or for an empty nodelist).
Yes. Types only exist in the function interface.

The declared type of the function you use a query for determines what the function gets.
NAME thanks. What about the operator interface? Operators are much like functions. Would it be correct to say that the comparison operators take arguments of type ValueType?
The spec doesn't say that. It could, be we decided against rolling out the (function) type system across the whole spec as it didn't seem to add much value, it would impact readability, and it is not without its own complexity. If you'd like to explore that option, please could we do it on the mailing list so it gets appropriate visibility? I don't think that topic is so relevant to this particular issue.
Back to the issue as proposed. We definitely need to say that. We also have to transfer all the other information from what is there now to the transposed form. I don't think the result would be an improvement.
We do say it, just not in those words. It's explicitly listed in the (new) table. What other information is there? I've stated all of the possible arguments for each parameter type. The improvement is the question that is answered. "Where can I put this argument?" vs "What kinds of things can I use for arguments to this function?" Users are going to ask the second question, not the first.
I think part of the difficulty in comparing the approach in this issue with the draft is that it's not obvious (at least to me) how much of section 2.4.3 the table would be replacing. I think it would be just section (2). Right? Even replacing just section (2), the following information is missing: What to do when a singular query is used as an argument for a parameter of type What to do when a query (including a singular query) is used as an argument for a parameter of type What to do when a function expression with result type is used as an argument for a parameter of type
I reordered (2) of 2.4.3 so related items are closed to each other (and the declared types also happen to be in alphabetical order).