Change:
2.5.5.2.4. Filter selectors may use function extensions, which are covered in <del> Section fnex. </del> <ins> fnex. </ins> 2.5.5.3.

Discussion:
This PR also addresses URL
My now implements everything in the spec, including this PR. (It also supports math operations in expressions, which isn't part of the spec (yet).) The function infrastructure was a struggle (mostly because I'm in a strongly typed language, I suspect), but once implemented, creating the functions themselves and registering them so that they can be parsed was easy! With my lib, the user would implement a "function definition" interface which exposes the name, the range of parameters expected (min/max), and the logic for the function itself (which follows a pattern defined in my lib). Once an instance of their definition is registered, it's available to be parsed. The parsing logic handles validating that the function receives the correct number of parameters, too, so if you send seven arguments, it'll fail to parse.
Tangentially related to , would we consider the use of a function as an argument to another function. Currently this is not allowed as a function is not a . An example for this may be: to determine if the maximum between and is less than 10.
Yes, I hope to support using the result of a function as an argument to a(nother) function in URL Note that I don't intend to support passing a function as an argument to a(nother) function or returning a function from a(nother) function, as in the following example, which does both:
FWIW I'd be fine with this being in a follow-up PR to .
It actually looks like this is already supported. can be a can be a takes zero or more s as parameters
Would we consider allowing advanced expressions usages? This would return the objects with s 1 and 4. (Yeah, we don't support currently, but the example illustrates the idea.) This would return the object with 1. There are probably other ways expressions could be used, too.
Note that function extensions, with the improvements anticipated in URL, may be able to address the above use cases:
I think what I've written is probably the more intuitive given the gamut of features in programming languages available today. What you have is definitely more functional (i.e. functional programming style), but I would tend toward using the operators for these examples. This issue isn't about "how could this be done with what we have?" but rather "is this something we want to support?"

Interestingly, I found a test in the comparison project that treats an expression as a : .
Here's . There is no consensus among implementations, although 14 of them behave the way this issue is proposing. (Embarrassingly, my Go implementation gets just the opposite of that result. That looks like a bug IIRC.)
2023-01-10 Interim: Do not do this enhancement.
Currently function extensions that return a nodelist must return a nodelist consisting of a single node. When a function extension is used as a comparable, it should be able to return an empty nodelist. When a function extension is used in an existence test, it should be able to return any number of nodes in its nodelist. (Currently, such an existence test always yields true since the returned nodelist is non-empty.)
Also if a function is used as an input to another function, it should be allowed to return multiple nodes.
Agreed. PR 330 addresses this.
This issue was addressed by PR .
I believe this is ready for merging (to serve as the next baseline). My comments can either be resolved or entered as new issues.