Change:
"{"j": 1, "k": 2}" must appear before "1" and "2", <del> "[5, 3, [{"j": 4}]]" must appear before "5", "3", and "[{"j": 4}]", </del> <ins> "[5, 3, [{"j": 4}, {"k": 6}]]" must appear before "5", "3", and "[{"j": 4}, {"k": 6}]", </ins> <del> "5" must appear before "3" which must appear before "[{"j": 4}]", </del> <ins> "5" must appear before "3" which must appear before "[{"j": 4}, {"k": 6}]", </ins> <del> "5" and "3" must appear before "{"j": 4}" and "4", </del> <ins> "5" and "3" must appear before "{"j": 4}", "4", ", {"k": 6}", and "6", </ins> <del> "[{"j": 4}]" must appear before "{"j": 4}", and </del> <ins> "[{"j": 4}, {"k": 6}]" must appear before "{"j": 4}" and "{"k": 6}", </ins> <del> "{"j": 4}" must appear before "4". </del> <ins> "{"j": 4}" must appear before "4", and "{"k": 6}" must appear before "6". </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> The example above with the query "$.a..[0, 1]" shows that the child segment "[0, 1]" is applied to each node in turn (rather than the nodes being visited once per selector, which is the case for some JSONPath implementations that do not conform to this specification). </ins> 3.7. Note that JSON "null" is treated the same as any other JSON value: it

Discussion:
Give an example to emphasise the spec behaviour. At the time of writing, this disagrees with the implementation consensus here: URL Fixes URL
Please see on the issue. I think we need more semantic text to define what we're looking for.
I've reworked the text in c7f54040f56756c2dd10e05cebbaa0d1a8fb31c1 to make the semantics much more obvious.
The current draft does not agree with the when a descendant segment has multiple selectors. The current draft says that a corresponding child segment containing the whole list of selectors should be applied to a descendant nodelist. The implementation consensus is that each selector is be applied to a descendant nodelist and the results concatenated together. Let's take an example involving arrays (to avoid non-determinism confusing matters). The JSONPath applied to the value according to the current draft gives: but according to the implementation consensus gives: One of the more influential implementations (Jayway) agrees with the current draft. I think it is best to go with the current draft behaviour as this can be implemented in a single traversal of the descendants, but wanted to confirm this here.
Another advantage of the current draft behaviour is that it is more deterministic than the implementation consensus. For example, the JSONPath applied to the value according to the current draft gives: or but according to the implementation consensus (with the non-determinism of URL) gives: or or or
I am very much in favor of cleaning this up. (If the odd behaviors are very widespread, we could combine the cleaned-up semantics with an interoperability warning that applications that rely on the exact sequence will be less interoperable than ones that don't. That is, of course, true of most of what the standard is providing...)
I agree that the current draft is better.
Reading the spec again, While it definitely has instruction for order the results of each selector, I don't think it specifies ordering one way or another for the multiple-selector case. Using the previous example there are two options: Each selector is analyzed separately and the results are concatenated. This is equivalent to (forgive the syntax) . This would (in theory) require multiple data traversals: one for matching and one for matching . All selectors are analyzed together for each node. This is more akin to (again, forgive the syntax) .

This would (in theory) process both selectors over a single traversal: as each node is visited, both selectors are applied. It sounds like we want the latter, traversal prioritization.
NAME You quoted an old version of the spec. The current spec says: I think this makes the multi-selector ordering clear.
I still think it's vague on the distinction I mentioned (the two options). Between the two options, I think this text leans more towards the selector prioritization, suggesting that the selector results in their entirety are concatenated.
See URL