Change:
3.4.8.2. <del> A list selector selects the nodes that are selected by at least one of the selector entries in the list and yields the concatenation of the lists (in the order of the selector entries) of nodes selected by the selector entries.  Note that any node selected in more than one of the selector entries is kept as many times in the nodelist. </del> <ins> A list selector selects the nodes that are selected by the selector entries in the list and yields the concatenation of the lists (in the order of the selector entries) of nodes selected by the selector entries.  Note that any node selected in more than one of the selector entries is kept as many times in the nodelist. </ins> To be valid, integer values in the "element-index" and "slice-index" components MUST be in the I-JSON RFC7493 range of exact values, see

Discussion:
Also tweak the wording of the list semantics section. Fixes URL Reviewers may find the useful.
NAME Just a gentle reminder to re-review as I'd like to get this PR merged. Thanks.
The (as of 2022-08-06) for the descendant selector involving a list: Do not state which descendants are selected. Order selected items contrary to current implementations. Lead to contradictions over the ordering of duplicate nodes. It is currently implicit that the list selector should select descendants based on the . This should be made explicit. An applies the path to the value: The spec states: Because of the ordering of the array, in all array-sequenced preorders of the above value, , , and appear before and which appear before which appears before which appears before . So the order of the result according to the spec is: However, the current consensus according to the comparison project is: where it seems the value is traversed once per item of the list (). Consider the path applied to the value: There is just one array-sequenced preorder of this value: (noting the clarification below). But the current produces duplicates and can reorder the elements of an array, so the resultant nodelist would be: which is not a sub-sequence of . We should make it clear that an array-sequenced preorder is of nodes rather than values. For example, consider the path applied to the value: The array-sequenced preorder of this value is and the values selected by are and , but the nodelist is not_ a valid result even though it is a subsequence of the values in the array-sequenced preorder. The result is which is a subsequence of the nodes in the array-sequenced preorder. (In fact, using an array of values to describe an array-sequenced preorder is misleading because it ignores the nodes' locations within the argument value.)
I propose the following actions: Clarify which nodes are selected. Preserve the current ordering, regardless of the implementation consensus, since it easily implemented via a single traversal of the descendants. Allow the descendant list selector to reorder a subsequence of the nodes in an array-sequenced preorder, although it must honour the order of the elements in the selector's list. Clarify the definition of array-sequenced preorder. Any objections?

I don't think you can tell about the ordering from this result, the query is flagged with footnote 4, see (URL), which indicates that these results are being sorted before comparison. A quick check shows that a number of implementations that fall in the consensus (including Goessner JavaScript) actually return
NAME well spotted (and thanks for raising URL). So that leaves the following proposed actions: Clarify which nodes are selected. Allow the descendant list selector to reorder a subsequence of the nodes in an array-sequenced preorder, although it must honour the order of the elements in the selector's list. Clarify the definition of array-sequenced preorder.
That sounds complicated :-) One thing to keep in mind is that implementations that return do not do anything complicated, nor do they "reorder a subsequence of the nodes in an array-sequenced preorder". Rather, they simply apply the selector to each node in the provided node list, and then (for the recursion operator) apply the same logic recursively on the children of each node. That description alone implies the above result.
I agree it sounds complicated. Perhaps, along the lines you describe, it is best to describe the possible orderings of descendants and then say how particular descendant selectors are apply to those descendants.
It may be helpful to think of the recursion operator as an operation that maps the current result list into a new result list according to the following rules: First, create a new empty result list. Then Iterate over the items of the current result list If the current item is an array or object, add it to the end of the new result list. If the current item is an array, iterate over its elements and apply these rules recursively to each element. If the current item is an object, iterate over its members and apply these rules recursively to each member value . This becomes the new current result list. So if the current result list contains the root value the recursive operation produces Then applying the selector to each element in the new current result list produces
I'd prefer to define the orderings of the descendants in terms of a postcondition rather than an algorithm because that avoids implementation bias - a useful property for a spec. Sometimes the postcondition form really doesn't work and we have to resort to an algorithm, for example in the slice semantics.

Let's see how the postcondition works out in a PR...
Oh and I would say that describing the part of the descendant selector as a recursion operator is another example of implementation bias (since implementations need not use recursion). The spec talks about descendant selectors because this term describes what the selectors are rather than how they are implemented.