Original text:
This section defines the extension point as well as four function extensions that use this extension point.  While these mechanisms are designed to use the extension point, they are an integral part of the <del> JSONPath specification and are mandatory to implement. </del>  A function extension defines a registered name (see iana-fnex) that can be applied to a sequence of zero or more arguments, producing a

Reviewer comments:
Fix a right margin incursion, as well.
I'm commenting on the editor's draft. Section 2.6 says, of len(), count(), match(), and search(), that “they are an integral part of the JSONPath specification and are mandatory to implement.” My intuition is that this is not consistent with the WG charter. I think we're supposed to be specifying the GCD of JSONPath implementations, not enriching the language. The actual words of the charter are “based on the common semantics and other aspects of existing implementations”. Do len(), count(), match(), and search() qualify?
Most implications support regexps in filters, so we need to support those somehow. A function extension seems like the neatest solution.
Most implementations also support length in some way, usually , which we've decided against.
Guilty as charged. In that sentence I tried to express that, although the four functions make use of an extension point, they are not extensions of the base standard, as are none of the other features defined in the document. We don't define compliance, but we do fan the expectation that a JSONPath implementation will not leave out a feature that seems inconvenient to implement (say, descendants segments). If you have better wording, we could take that.
In all implementations there is some degree or level of compliance with the specification. No matter what the wording is in the specification the implementations will stand as they are and users will evaluate them based on how well or how compliant it is with the spec but more importantly how useful they are to them. In my implementation for go I have not yet implemented functions but do support regex with a . As this specification solidifies I'll also support the changes but in the interest of not breaking existing code that uses the OjG package I'll keep the original implementation as well.
NAME that's expected from most implementers, including myself. However, also as one of the editors, I would hope that implementors default to spec compliant behavior, offering other functionality behind options that the user must explicitly set. This is fairly common for spec implementations and what I will be doing if I decide to support extra-spec functionality.
I may not put it as eloquently as you do but I agree 100%. I hope I can contribute at some point.

Revised text:
This section defines the extension point as well as four function extensions that use this extension point.  While these mechanisms are designed to use the extension point, they are an integral part of the  <ins> JSONPath specification and are expected to be implemented like any other integral part of this specification. </ins> A function extension defines a registered name (see iana-fnex) that can be applied to a sequence of zero or more arguments, producing a