Change:
2.5.5.2.3. <del> A regular-expression test yields true if and only if the value on the left-hand side of "=~" is a string value and it matches the regular expression on the right-hand side according to the semantics of I- D.draft-ietf-jsonpath-iregexp. The semantics of regular expressions are as defined in I-D.draft- ietf-jsonpath-iregexp. </del> <ins> The logical AND, OR, and NOT operators have the normal semantics of Boolean algebra and obey its laws (see, for example, BOOLEAN-LAWS). </ins> 2.5.5.2.4. <del> The logical AND, OR, and NOT operators have the normal semantics of Boolean algebra and obey its laws (see, for example, BOOLEAN-LAWS). </del> <ins> [unnumbered-bad] Beyond the filter expression functionality defined in the preceding subsections, JSONPath defines an extension point that can be used to add filter expression functionality: "Function Extensions". A function extension defines a registered name (see iana-fnex) that can be applied to a sequence of zero or more arguments, resulting in a result.  A function-expression stands for ("returns") a nodelist or a value.  The arguments are filter expressions that are to be interpreted as nodelists or values.  For each argument and for the result, the function extension defines the "kind" of the item, i.e., whether the item is a value or a nodelist ("nodes"). Syntactically, a function-expression can occur anywhere where a singular-path can occur (exist-expr, comparable).  A function- expression that employs a function extension that returns a nodelist MUST return a singular node to be used in a comparable. 2.5.5.2.4.1. The "length" function extension provides a way to compute the length of a value and make that available for further processing in the filter expression: Its only argument is a value (possibly taken from a singular path as in the example above).  The result also is a value, an unsigned integer. If the argument value is a string, the result is the number of Unicode scalar values in the string. If the argument value is an array, the result is the number of elements in the array. If the argument value is an object, the result is the number of members in the object. For any other argument value, the result is one. 2.5.5.2.4.2. The "count" function extension provides a way to obtain the number of nodes in a nodelist and make that available for further processing in the filter expression: Its only argument is a nodelist.  The result is a value, an unsigned integer, that gives the number of nodes in the nodelist.  Note that there is no deduplication of the nodelist. [dedup] 2.5.5.2.4.3. The "match" function extension provides a way to check whether (the entirety of, see search below) a given string matches a given regular expression, which is in I-D.draft-ietf-jsonpath-iregexp form. Its first argument is a string that is matched against the iregexp contained in the string that is the second argument.  The result is "true" if the string matches the iregexp and "false" otherwise. 2.5.5.2.4.4. The "search" function extension provides a way to check whether a given string contains a substring that matches a given regular expression, which is in I-D.draft-ietf-jsonpath-iregexp form. Its first argument is a string that is searched for at least one substring that matches the iregexp contained in the string that is the second argument.  The result is "true" if such a substring exists, "false" otherwise. o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o </ins> 2.5.5.3.

Discussion:
Weirdly, I cannot reply to this observation: URL Expiry is somewhat unusual for IANA registries (early allocations do expire). What is the behavior you would expect implementations to exhibit? The function extension to stop working on the expiry day?
Hey NAME based on this useful-looking discussion, do you plan to revise this significantly? I'm wondering if I should give it a careful read now or wait for an updated version.
Definitely. Of course, I'd like to have your input on the points raised (the non-trivial ones). We might even want to have a design-team meeting...
Might be a good idea to mark the non-non-trivial issues above resolved, to help reviewer focus. If it's OK, I'll wait for the next revision to go end-to-end. Agreed on a design meeting.
Here's my list of items where we could use input: More frugal with allowing whitespace? return value of functions that don't get the right arguments (e.g., length(1)) (interaction with -- non-singular paths in exist-expr) IANA designated expert instructions (frugal with "good" names) expiring reservations? (shades of certificates) domain of length (arrays now, add strings, objects?)? should there be another function for the size of nodelists (size())? Probably mostly resolved: for function names (ASCII, lowercase, only)
NAME I rebased this and resolved some conflicts.
Update: Address whitespace in a separate PR, if desired. Semantic issue: What to do with value of wrong kind? Fixed in 08dd7ad Fixed in afda44a Probably not. Semantic issue: What to do with value of wrong kind? Yes, that is called count() now (e3a565a) Let's stick with that name space.
We may be able to make this syntactically invalid. See URL for some ideas.