Change:
3.5.5.2.1. <del> A singular path by itself in a Boolean context is an existence test which yields true if the path selects a node and yields false if the path does not select a node.  This existence test -- as an exception to the general rule -- also works with nodes with structured values. </del> <ins> A path by itself in a Boolean context is an existence test which yields true if the path selects at least one node and yields false if the path does not select any nodes. Existence tests differ from comparisons in that: they work with arbitrary relative or absolute paths (not just Singular Paths). they work with paths that select structured values. </ins> To test the value of a node selected by a path, an explicit comparison is necessary.  For example, to test whether the node

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.