Original text:
expression, usually involving the current node, is evaluated and the current node is selected if and only if the expression yields true.  The current node is accessible via the current node identifier "@". This identifier addresses the current node of the filter-selector that is directly enclosing the identifier; note that within nested can be applied to a sequence of zero or more arguments, producing a result.  A function argument is a "filter-path" or a "comparable". According to filter-selector, a "function-expression" is valid as a

Reviewer comments:
clarify that filter expressions are side-effect free and therefore, short-circuiting does not make a difference
In C# (and probably other C-style languages), there are two variants for these operators. and are simple boolean logic. They evaluate all of their operands always (left to right). and are "short-circuit" logic. Their operands are evaluated left to right, and as soon as an outcome is known, it stops evaluating. For example, in , the is never evaluated because returns false so the evaluator knows the entire expression will be false. This becomes important for C# as the operands may be methods which have side effects. If I am trying to parse a , then use the I parsed, I can do that all in one statement: (assume returns a ) In this case, never gets called, which means that no log entry is made. But if I use instead will always be called and a log entry will always be created. ( will be the default (0), but it will still be called.) I'm not sure whether we care about such side effects in JSON Path (I'm leaning towards probably not), but it seems necessary to raise the issue. I expect that if we don't care about side effects, this comes down to an optimization strategy and implementor's choice.
This may become more important if certain function extensions end up having side effects. Perhaps we should say implementations MAY short circuit evaluation. Then it's up to users and function extensions to cope.
Actually, it would already become important as soon as we have exception-like semantics on subexpressions. I'd prefer not to have them.
2023-01-10 Interim: Add text that explicitly excludes side effects that affect the evaluation of JSONpath (e.g., beyond memoization or logging), but makes clear that short-circuiting is a valid implementation strategy; functions need to be pure functions.

Revised text:
expression, usually involving the current node, is evaluated and the current node is selected if and only if the expression yields true. <ins> As the expression is composed of side-effect free components, the order of evaluation does not need to be (and is not) defined. Similarly, for "&&"/"||", both a short-circuiting and a fully evaluating implementation will lead to the same result; both implementation strategies are therefore valid. </ins> The current node is accessible via the current node identifier "@". This identifier addresses the current node of the filter-selector that is directly enclosing the identifier; note that within nested can be applied to a sequence of zero or more arguments, producing a result. <ins> A function extension MUST be defined such that its evaluation is side-effect free, i.e., all possible orders of evaluation and choices of short-circuiting or full evaluation of an expression containing it must lead to the same result.  (Note that memoization or logging are not side effects in this sense as they are visible at the implementation level only -- they do not influence the result of the evaluation.) </ins> A function argument is a "filter-path" or a "comparable". According to filter-selector, a "function-expression" is valid as a