Original text:
tbl-overview provides a quick overview of the JSONPath syntax elements.  2. This section provides some more examples for JSONPath expressions. , i.e., a sequence of zero or more nodes.  The nodelist resulting from the root identifier contains a single node, the argument.  The nodelist resulting from the last segment is presented as the result of the query; depending on the specific API, As a consequence of this approach, if any of the segments produces an empty nodelist, then the whole query produces an empty nodelist. <del> In what follows, the semantics of each segment are defined for each type of node.  It will turn out that the more segments there are in a query, the greater the depth of the nodes of the resultant nodelist in the input value: </del>  <del> A query with N segments, where N >= 0, produces a nodelist consisting of nodes at depth in the input value of N or greater. A query with N segments, where N >= 0, all of which are child- segment, produces a nodelist consisting of nodes precisely at depth N in the input value. </del>  3.4. 3.5.2.2. A "wildcard" selector selects the nodes of all children of an object <del> or array. </del>  The "wildcard" selector selects nothing from a primitive JSON value (that is, a number, a string, "true", "false", or "null"). The following examples show the "wildcard" selector in use by a child segment.  3.5.3. 3.5.3.1. of their array elements or member values, respectively.  Applied to other value types, it will select nothing.  A relative path, beginning with "@", refers to the current array element or member value as the filter selector iterates over the array or object. Queries:  3.6. Segments apply one or more selectors to an input value and concatenate the results into a single nodelist.  The syntax and semantics of each segment are defined below. 3.6.1. appear in the list.  Note that any node matched by more than one selector is kept as many times in the nodelist.  3.6.2. 3.6.2.1. A descendant segment produces zero or more descendants of the input value. <del> A nodelist enumerating the descendants is known as a </del>  <del> when: </del>  <del> nodes of any array appear in array order, </del>  <del> nodes appear immediately before all their descendants. </del>  This definition does not stipulate the order in which the children of <del> an object appear, since JSON objects are unordered. </del>  <del> The resultant nodelist of a descendant segment of the form "..[<selectors>]" is the result of applying the child segment "[<selectors>]" to a descendant nodelist. </del>  3.6.2.3. "{"j": 4}" must appear before "4".  3.7. Note that JSON "null" is treated the same as any other JSON value: it

Reviewer comments:
This PR is a series of changes which are submitted together since they would tread on each other's toes if submitted separately. Fixes URL Fixes URL
NAME I'm going to merge this so I can progress other changes. I'd still appreciate your review and I will apply any fixes in a subsequent PR.
Currently, the JSONPath spec is insufficiently non-deterministic. According to the current draft, in a descendant nodelist, nodes appear immediately before all their descendants. In the example given in the spec, the selector applied to the JSON value: cannot produce the result shown in the table: since does not appear immediately before and (there is an intervening ). Solution: delete the word "immediately". The iteration order of objects is not guaranteed to be the same from one iteration to the next. (For instance, in Go, a JSON object is usually implemented as a map and, according to the , "The iteration order over maps is not specified and is not guaranteed to be the same from one iteration to the next".) So a list with more than one entry applied to an object can result in a nodelist in which there are sublists in distinct orders. This is the case if each list entry in turn is used to select a nodelist from the object. For example, the JSONPath applied to the value: could produce the nodelist: The descendant selectors can produce similar effects, both in the ordering of the descendant nodelists and in the list form with examples similar to that above. For example, the JSONPath applied to the value: can produce the nodelist: Repeated applications of a JSONPath to a value can result in nodelists which are ordered differently. For example, the JSONPath applied to the value: could produce the nodelist: on one occasion and the nodelist: on a subsequent occasion. Currently, there is no text to define the order of the nodelist resulting from a dot wildcard, index wildcard, or filter selector. The order should preserve array order, but be non-deterministic for objects.
Clarification: Do you mean that the spec should be more non-deterministic? I expect that you mean you want more determinism.
How would you get 4 results from this? I'd expect the output to be just and (in any order).
I agree with the sentiment here. The unorderedness of objects in general is likely going to be an issue for testing.
No. I want less determinism to allow sufficient freedom for implementations.
Oops. Of course. Fixed above.
Should we avoid specifying the order of results at all then? Or, more directly, explicitly state the the order of elements in a nodelist may be determined by the implementation and, because of non-determinism among various JSON implementations, is not subject to consistency?
No, that would be going much too far. For example, it's important that arrays still produce array-ordered nodelists. I agree with that statement, but I wouldn't want to litter the spec with that in multiple places. I'd prefer to use similar language to the current draft, e.g.:
As part of addressing this issue, if PR is merged, we should also define the ordering of resultant nodelists from child and descendant *selectors.
I think the spec should be specific and say that when the nodelist is constructed from members of objects, its ordering is undefined, because the fact that the ordering is not defined for objects. Let's take this issue up tomorrow.
At the 2022-9-27 interim, there was general agreement to implement this issue. There is a need for more extensive examples, especially showing multi-layered cases. There is a concern about how to make a test suite tractable given the level of non-determinism which is being allowed by the spec. The plan is to attack this issue after lands.
The current draft applies descendant selectors to the (strict) descendants of the input value. However, as mentioned in URL, it would better reflect current implementations if descendant selectors applied to the input value as well as its descendants. The comparison project has a for this which shows a consensus among existing implementations.
See URL
NAME I think it would still be legitimate to call the descendant selectors by that name since the values they select are all descendants of the input value. (The one exception would be if we were to allow on its own, in which case the input value would be in the resultant nodelist.)
At the 2022-9-27 interim meeting there was a consensus for implementing this issue.
This sounds a lot better. Just a minor grammatical issue.

Revised text:
tbl-overview provides a quick overview of the JSONPath syntax elements. <ins> This document treats the bracket notations as canonical and defines the above shorthands in terms of the canonical bracket notation. </ins> 2. This section provides some more examples for JSONPath expressions. , i.e., a sequence of zero or more nodes. <ins> Segments can be added to a query to drill further into the structure of the input value. </ins> The nodelist resulting from the root identifier contains a single node, the argument.  The nodelist resulting from the last segment is presented as the result of the query; depending on the specific API, As a consequence of this approach, if any of the segments produces an empty nodelist, then the whole query produces an empty nodelist.  <ins> If a query may produce a nodelist with more than one possible ordering, a particular implementation may also produce distinct orderings in distinct runs of the query. </ins>  <ins> In what follows, the semantics of each segment are defined for each type of node. </ins> 3.4. 3.5.2.2. A "wildcard" selector selects the nodes of all children of an object  <ins> or array.  The order in which the children of an object appear in the resultant nodelist is not stipulated, since JSON objects are unordered.  Children of an array appear in array order in the resultant nodelist. </ins> The "wildcard" selector selects nothing from a primitive JSON value (that is, a number, a string, "true", "false", or "null"). The following examples show the "wildcard" selector in use by a child segment. <ins> The example above with the query "$.o[*, *]" shows that the wildcard selector may produce nodelists in distinct orders each time it appears in the child segment. </ins> 3.5.3. 3.5.3.1. of their array elements or member values, respectively.  Applied to other value types, it will select nothing. <ins> The order in which the children of an object appear in the resultant nodelist is not stipulated, since JSON objects are unordered. Children of an array appear in array order in the resultant nodelist. </ins> A relative path, beginning with "@", refers to the current array element or member value as the filter selector iterates over the array or object. Queries: <ins> The example above with the query "$.a[?@.b, ?@.b]" shows that the filter selector may produce nodelists in distinct orders each time it appears in the child segment. </ins> 3.6. Segments apply one or more selectors to an input value and concatenate the results into a single nodelist. <ins> It turns out that the more segments there are in a query, the greater the depth in the input value of the nodes of the resultant nodelist: A query with N segments, where N >= 0, produces a nodelist consisting of nodes at depth in the input value of N or greater. A query with N segments, where N >= 0, all of which are child- segment, produces a nodelist consisting of nodes precisely at depth N in the input value. </ins> The syntax and semantics of each segment are defined below. 3.6.1. appear in the list.  Note that any node matched by more than one selector is kept as many times in the nodelist. <ins> So a child segment drills down one more level into the structure of the input value. </ins> 3.6.2. 3.6.2.1. A descendant segment produces zero or more descendants of the input value.  <ins> A descendant selector of the form "..[<selectors>]" visits each node of the input value and its descendants in such an order that: </ins>  <ins> nodes of any array are visited in array order, and </ins>  <ins> nodes are visited before all their descendants. </ins>  <ins> It applies the child segment "[<selectors>]" to each node and concatenates the resultant nodelists together in the order in which the nodes were visited. </ins> This definition does not stipulate the order in which the children of  <ins> an object are visited, since JSON objects are unordered. Where a selector can produce a nodelist in more than one possible order, the selector may produce nodelists in distinct orders each time it appears in the descendant segment. </ins>  <ins> So a descendant segment drills down one or more levels into the structure of the input value. </ins> 3.6.2.3. "{"j": 4}" must appear before "4". <ins> The example above with the query "$.o..[*, *]" shows that a selector may produce nodelists in distinct orders each time it appears in the descendant segment. </ins> 3.7. Note that JSON "null" is treated the same as any other JSON value: it