Change:
, 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,

Discussion:
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.