Change:
A descendant segment produces zero or more descendants of the input value. <del> A descendant selector of the form "..[<selectors>]" visits each node of the input value and its descendants in such an order that: </del> <ins> A descendant selector visits the input value and each of its descendants such that: </ins> nodes of any array are visited in array order, and <del> nodes are visited before all their descendants. </del> <ins> nodes are visited before their descendants. </ins> <del> It applies the child segment "[<selectors>]" to each node and concatenates the resultant nodelists together in the order in which the nodes were visited. </del> <ins> The order in which the children of an object are visited is not stipulated, since JSON objects are unordered. </ins> <del> This definition does not stipulate the order in which the children of an object are visited, since JSON objects are unordered. </del> <ins> Suppose the nodes, in the order visited, are "D1", ..., "Dn" (where "n >= 1").  Note that "D1" is the input value. </ins> <del> 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. </del> <ins> For each "i" such that "1 <= i <= n", the nodelist "Ri" is defined to be a result of applying the child segment "[<selectors>]" to the node "Di". The result of the descendant selector is the concatenation of "R1", ..., "Rn" (in that order). </ins> So a descendant segment drills down one or more levels into the structure of the input value.

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