Change:
Parentheses MAY be used within "boolean-expr" for grouping. <del> Comparisons are restricted to Singular Path values and primitive values (that is, numbers, strings, "true", "false", and "null"). </del> <ins> Comparisons are restricted to Singular Path values, each of which selects at most one node, and primitive values (that is, numbers, strings, "true", "false", and "null"). </ins> Alphabetic characters in ABNF are case-insensitive, so "e" can be either "e" or "E".

Discussion:
Fixes URL
Usually, existence could be asked in the form "is there any...". We restrict exist-expr to singular paths, though. Do we really want to make this restriction?
I'm trying to think how this would be done practically. All the examples for existence testing are in the form (as you mention). What sorts of plural paths are you suggesting could also test for existence? The only one I can think of would be which I suppose could return any non-empty objects.
-- which top level elements have sub-elements with a fallback member?
It's not obvious to me what you're expecting here. Consider If we try with Jayway JSONPath, an implementation that evaluates as a test for existence, and supports arbitrary JSONPath expressions in filter predicates, we obtain With Jayway semantics, all the evaluations of have to return true for to be accepted.
NAME yes, good question. Note Jayway's logical treatment of existence of all members of an empty set. Evaluating against yields:
Obviously, if the path is no longer singular, there needs to be a definition if this is a ∀ for-all (as in Jayway) or an ∃ exists (as I would have expected from the name).
I see no problem with this. I would also expect this to be an "any exists" operation. Framed more verbosely, the query says "find all children of the root array for which returns a non-empty set." This interpretation would return the first two sub-arrays.
Just to follow up with a comparison with JSONPath, which is another of the dozen implementations in the JSONPath Comparisons that evaluate as a test for existence. Of these dozen implementations, Jayway and Newtonsoft are clearly the most important. Java Jayway is likely the most widely used of all implementations, and is incorporated in Oracle enterprise API's. Newtonsoft JSON.Net shows 2 billion downloads on NuGet. Given and query Newtonsoft JSONPath returns no results. However, given, to my eye, the more natural query Newtonsoft JSONPath returns Jayway, in contrast, when given returns everything,
(Newtonsoft is losing importance as .Net's built-in JSON support continues to grow. Newtonsoft's download count is due to it being available for a couple decades. It's not a good metric to convey current state.)

All the more impressive that Newtonsoft's JSONPath is more expressive than the Committee's attempts :-) At least with supporting a natural query that returns NAME preferred result. Best regards, Daniel
I agree that Newtonsoft's .Net JSONPath isn't as important as Jayway Java JSONPath, which is older. I don't think JSONPath ever achieved the popularity on .Net that Jayway did in Java, where it got incorporated into Oracle enterprise API's. In .Net, users were more likely, once the JSON was mapped into C# types, to use Microsoft technologies, notably LINQ, to query them. On Stack Overflow, it sometimes seems that Jayway JSONPath is JSONPath, to users, who rarely qualify their questions by mentioning the implementation, and to responders, who answer accordingly. For example, a recent questioner asked about the function, which Jayway has, but otherwise is not common. A responder replied referencing a Jayway online site. Neither questioner or responder specifically mentioned "Jayway", but they obviously had a common frame of reference.
Currently, the only relative (NAME path we have is: That would need to be generalized for exist-expr.
NAME I've deleted my comment as it was nonsense! (Probably caused by thoughts of being termed a selector.)
Let's keep this issue open and revisit it as the spec firms up. This was agreed at the 2022-9-27 interim.
I will attempt to add a comparison project test as part of this.
Added: URL There is no calculated consensus among implementations.
Looks like a lot of them do either reject the syntax or otherwise fail to evaluate it, though.
I think that gives us freedom to define this feature the way we want. Compare filter selectors without the outer parentheses (e.g. ) which I'm sure most, if not all, existing implementations would reject with a syntax error.
I'm happy with the textual changes. I'd prefer NAME or someone else look at the ABNF.