Change:
Add clarifications that the input nodelist provides the outer order, the segments provide a middle-level order, and selectors (if multiple) provide the inner order. This may have been obvious to some readers, but now should be obvious to more, including yours truly.
I don't think the example for in Table 17 is right. URL It says: It should be: Note that the descendants list puts out before and . The wildcard selector then has no choice but outputting , , , .
Nice catch! The example needs fixing as does the ordering note below Table 17.
I let the computer do the catching :-) Do you want to make these changes? I'd do a new issue then. (And wait a bit for Greg to catch up.)
NAME Yes, I'm happy to do that and please do create a new issue. I won't be able to fix it before the weekend at the earliest though.
URL
LGTM thanks. Semantics unchanged, but hopefully a lot clearer.

Discussion:
empty nodelist is a valid query result. A segment operates on each of the nodes in its input nodelist in <del> turn, and the resultant nodelists are concatenated to produce the result of the segment.  A node may be selected more than once and appears that number of times in the nodelist.  Duplicate nodes are not removed. </del> <ins> turn, and the resultant nodelists are concatenated in the order of the input nodelist they were derived from to produce the result of the segment.  A node may be selected more than once and appears that number of times in the nodelist.  Duplicate nodes are not removed. </ins> A syntactically valid segment MUST NOT produce errors when executing the query.  This means that some operations that might be considered

2.7. <del> Segments apply one or more selectors to an input value and concatenate the results into a single nodelist. </del> <ins> For each node in an input nodelist, segments apply one or more selectors to the node and concatenate the results of each selector into per-input-node nodelists, which are then concatenated in the order of the input nodelist to form a single segment result 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:

Selectors of different kinds may be combined within a single child segment. <del> The resulting nodelist of a child segment is the concatenation of the nodelists from each of its selectors in the order that the selectors appear in the list.  Note that any node matched by more than one selector is kept as many times in the nodelist. </del> <ins> For each node in the input nodelist, the resulting nodelist of a child segment is the concatenation of the nodelists from each of its selectors in the order that the selectors appear in the list.  Note that any node matched by more than one selector is kept as many times in the nodelist. </ins> Where a selector can produce a nodelist in more than one possible order, each occurrence of the selector in the child segment may

2.7.2.2. <del> A descendant segment produces zero or more descendants of the input </del> <ins> A descendant segment produces zero or more descendants of an input </ins> value. <del> A descendant selector visits the input value and each of its descendants such that: </del> <ins> For each node in the input nodelist, a descendant selector visits the input node and each of its descendants such that: </ins> nodes of any array are visited in array order, and

be a result of applying the child segment "[<selectors>]" to the node "Di". <del> The result of the descendant selector is the concatenation of "R1", ..., "Rn" (in that order). </del> <ins> For each node in the input nodelist, the result of the descendant segment is the concatenation of "R1", ..., "Rn" (in that order). These results are then concatenated in input nodelist order to form the result of the segment. </ins> So a descendant segment drills down one or more levels into the <del> structure of the input value. </del> <ins> structure of each input value. </ins> 2.7.2.3.