Original text:
)-1]. <del> Strings on the right-hand side of the "=~" regex matching operator MUST conform to I-D.draft-ietf-jsonpath-iregexp. </del> The well-formedness and the validity of JSONPath queries are independent of the JSON value the query is applied to; no further errors relating to the well-formedness and the validity of a JSONPath "true", "false", and "null" are lower-case only (case-sensitive). <del> The syntax of regular expressions in the string-literals on the right-hand side of "=~" is as defined in I-D.draft-ietf-jsonpath- iregexp. </del> The following table lists filter expression operators in order of precedence from highest (binds most tightly) to lowest (binds least tightly). 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>  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>  2.5.5.3. depth N in the input value. There are two kinds of segment: child segments and descendant <del> segments.  ~~~~ abnf segment = child-segment / descendant-segment ~~~~ </del>  The syntax and semantics of each kind of segment are defined below. Person & email address to contact for further information: iesg@ietf.org  4. Security considerations for JSONPath can stem from Other attacks can target the behavior of underlying technologies such as UTF-8 (see RFC3629) and the Unicode character set. 

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

Revised text:
)-1].  The well-formedness and the validity of JSONPath queries are independent of the JSON value the query is applied to; no further errors relating to the well-formedness and the validity of a JSONPath "true", "false", and "null" are lower-case only (case-sensitive).  The following table lists filter expression operators in order of precedence from highest (binds most tightly) to lowest (binds least tightly). 2.5.5.2.3.  <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.  <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. depth N in the input value. There are two kinds of segment: child segments and descendant  <ins> segments. </ins> The syntax and semantics of each kind of segment are defined below. Person & email address to contact for further information: iesg@ietf.org <ins> 3.2. This specification defines a new "Function Extensions sub-registry" in a new "JSONPath Parameters registry", with the policy "expert review" (BCP26). The experts are instructed to be frugal in the allocation of function extension names that are suggestive of generally applicable semantics, keeping them in reserve for functions that are likely to enjoy wide use and can make good use of their conciseness.  The expert is also instructed to direct the registrant to provide a specification (BCP26), but can make exceptions, for instance when a specification is not available at the time of registration but is likely forthcoming.  If the expert becomes aware of function extensions that are deployed and in use, they may also initiate a registration on their own if they deem such a registration can avert potential future collisions. Each entry in the registry must include: Initial entries in this sub-registry are as listed in pre-reg: </ins> 4. Security considerations for JSONPath can stem from Other attacks can target the behavior of underlying technologies such as UTF-8 (see RFC3629) and the Unicode character set. <ins> Editorial Comments [unnumbered-bad] -- cabo: This should not be an unnumbered section, which it is forced to be by the parent section being unnumbered too.  The overall structure where the parts of this subsection go to needs to be decided; one part already is in the IANA Considerations in [dedup] Well, that can be discussed. </ins>