Original text:
Array slice selector "[<start>:<end>:<step>]", where the optional values "<start>", "<end>", and "<step>" are integer literals <del> Descendants selectors starting with a double dot ".." </del> List selector "[<sel1>,<sel2>,...,<selN>]", holding a comma separated list of index and slice selectors Filter selector "[?(<expr>)]" Current item selector "@" (used in expressions)  Note that processing the dot selector, string-valued index selector, and filter selector all potentially require matching strings against strings, with those strings coming from the JSONPath and from member 3.4.7.1. <del> The descendant selectors start with a double dot ".." and can be followed by an object member name (similar to the "dot-selector"), a wildcard (similar to the "dot-wild-selector"), an "index-selector", "index-wild-selector", "filter-selector", or "list-selector" acting on objects or arrays, or a "slice-selector" acting on arrays. Note that ".." on its own is not a valid selector. 3.4.7.2. A "descendant-selector" selects certain descendants of a node: the "..<name>" form (and the "..[<index>]" form where "<index>" is a "quoted-member-name") selects those descendants that are member values of an object with the given member name. the "..[<index>]" form, where "<index>" is an "element-index", selects those descendants that are array elements with the given index. the "..[<slice-index>]" form selects those descendants that are array elements selected by the given slice. the "..[<filter>]" form selects those descendants that are array elements or object values selected by the given filter. the "..[*]" and "..*" forms select all the descendants. An of the descendants of a node is a sequence of all the descendants in which: nodes of any array appear in array order, nodes appear immediately before all their descendants. This definition does not stipulate the order in which the children of an object appear, since JSON objects are unordered. The resultant nodelist of a "descendant-selector" applied to a node must be a sub-sequence of an array-sequenced preorder of the descendants of the node. 3.4.7.3. JSON: Queries: Note: The ordering of the results for the "$..[*]" and "$..*" examples above is not guaranteed, except that: "{"j": 1, "k": 2}" must appear before "1" and "2", "[5, 3, [{"j": 4}]]" must appear before "5", "3", and "[{"j": 4}]", "5" must appear before "3" which must appear before "[{"j": 4}]", "5" and "3" must appear before "{"j": 4}" and "4", "[{"j": 4}]" must appear before "{"j": 4}", and "{"j": 4}" must appear before "4". 3.4.8. 3.4.8.1. </del> The filter selector has the form "[?<expr>]".  It works via iterating over structured values, i.e. arrays and objects. precedence from highest (binds most tightly) to lowest (binds least tightly). <del> 3.4.8.2. </del>  The "filter-selector" works with arrays and objects exclusively.  Its result is a list of element or member value as the filter selector iterates over the array or object. <del> 3.4.8.2.1. </del>  A singular path by itself in a Boolean context is an existence test which yields true if the path selects a node and yields false if the "!@.foo" (which yields false if "@.foo" selects a node, regardless of the node's value). <del> 3.4.8.2.2. </del>  When a path resulting in an empty nodelist appears on either side of a comparison, the comparison yields true if and only if: comparisons between a structured value and any value, including the same structured value, yield true. <del> 3.4.8.2.2.1. </del>  JSON: <del> 3.4.8.2.3. </del>  A regular-expression test yields true if and only if the value on the left-hand side of "=~" is a string value and it matches the regular The semantics of regular expressions are as defined in I-D.draft- bormann-jsonpath-iregexp. <del> 3.4.8.2.4. </del>  The logical AND, OR, and NOT operators have the normal semantics of Boolean algebra and consequently obey these laws (where "P", "Q", and expression that yields true, such as "1 == 1", and "F" is any expression that yields false, such as "1 == 0"): <del> 3.4.8.3. </del>  JSON: Queries: <del> 3.4.9. </del>  The list selector allows combining member names, array indices, slices, and filters in a single selector. operation that involves merging input sets while avoiding duplicates, so the concept was renamed into "list selector". <del> 3.4.9.1. </del>  The list selector is syntactically related to the "dot-selector", "index-selector", "slice-selector", and the "filter-selector".  It contains two or more entries, separated by commas. <del> 3.4.9.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 components MUST be in the I-JSON range of exact values, see synsem- overview.  3.4.9.3. JSON: Queries:  3.5. Note that JSON "null" is treated the same as any other JSON value: it

Reviewer comments:
I want to take the opportunity of there being no PRs in flight to make this purely editorial change to the order of the spec. It avoids unnecessary forward references to the filter and list selectors.
Another PR opened and merged in less than 8 hours...
Please note this PR was purely editorial. It moved some text around. but didn't change it. (I was planning to merge this later today after a bit more time.)
We should just have a flat policy of 24 hrs for a PR to ensure everyone gets to see it. It doesn't matter if it was a spelling change. Everyone should have a chance to review it.
It's one thing to agree to this policy, which I think we have, and quite another to remember to apply it when one is focussed on other things. I've raised a about automating this check.
Have we? It is not policy I would normally agree to. Editors need to be able to do their work. Github is here to help, not to hinder.
Ah, my mistake: I agreed.
We have a two-week policy for PRs in JSON Schema and it's very helpful to encourage cooperation. I don't think 24 hrs is too much to ask.
Please explain how you did not get a chance to review this change.
The PR opened at 3AM and merged at 10AM. This is an insufficient window. 24 hrs, please. It's not a big request.
You have had time to review after merge. How is a merge such an important event?
If I have objections to a PR, they should be voiced before it's merged. Reviewing after the fact is pointless. Any damage has been done. This particular PR is not one of those cases, but in general, everyone involved should get a chance to review. Why are you so opposed to this? It's one day. That's all I'm asking.
Thanks!

Revised text:
Array slice selector "[<start>:<end>:<step>]", where the optional values "<start>", "<end>", and "<step>" are integer literals  List selector "[<sel1>,<sel2>,...,<selN>]", holding a comma separated list of index and slice selectors Filter selector "[?(<expr>)]" Current item selector "@" (used in expressions) <ins> Descendants selectors starting with a double dot ".." </ins> Note that processing the dot selector, string-valued index selector, and filter selector all potentially require matching strings against strings, with those strings coming from the JSONPath and from member 3.4.7.1.  The filter selector has the form "[?<expr>]".  It works via iterating over structured values, i.e. arrays and objects. precedence from highest (binds most tightly) to lowest (binds least tightly).  <ins> 3.4.7.2. </ins> The "filter-selector" works with arrays and objects exclusively.  Its result is a list of element or member value as the filter selector iterates over the array or object.  <ins> 3.4.7.2.1. </ins> A singular path by itself in a Boolean context is an existence test which yields true if the path selects a node and yields false if the "!@.foo" (which yields false if "@.foo" selects a node, regardless of the node's value).  <ins> 3.4.7.2.2. </ins> When a path resulting in an empty nodelist appears on either side of a comparison, the comparison yields true if and only if: comparisons between a structured value and any value, including the same structured value, yield true.  <ins> 3.4.7.2.2.1. </ins> JSON:  <ins> 3.4.7.2.3. </ins> A regular-expression test yields true if and only if the value on the left-hand side of "=~" is a string value and it matches the regular The semantics of regular expressions are as defined in I-D.draft- bormann-jsonpath-iregexp.  <ins> 3.4.7.2.4. </ins> The logical AND, OR, and NOT operators have the normal semantics of Boolean algebra and consequently obey these laws (where "P", "Q", and expression that yields true, such as "1 == 1", and "F" is any expression that yields false, such as "1 == 0"):  <ins> 3.4.7.3. </ins> JSON: Queries:  <ins> 3.4.8. </ins> The list selector allows combining member names, array indices, slices, and filters in a single selector. operation that involves merging input sets while avoiding duplicates, so the concept was renamed into "list selector".  <ins> 3.4.8.1. </ins> The list selector is syntactically related to the "dot-selector", "index-selector", "slice-selector", and the "filter-selector".  It contains two or more entries, separated by commas.  <ins> 3.4.8.2. </ins> 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 components MUST be in the I-JSON range of exact values, see synsem- overview. <ins> 3.4.8.3. JSON: Queries: 3.4.9. 3.4.9.1. The descendant selectors start with a double dot ".." and can be followed by an object member name (similar to the "dot-selector"), a wildcard (similar to the "dot-wild-selector"), an "index-selector", "index-wild-selector", "filter-selector", or "list-selector" acting on objects or arrays, or a "slice-selector" acting on arrays. Note that ".." on its own is not a valid selector. 3.4.9.2. A "descendant-selector" selects certain descendants of a node: the "..<name>" form (and the "..[<index>]" form where "<index>" is a "quoted-member-name") selects those descendants that are member values of an object with the given member name. the "..[<index>]" form, where "<index>" is an "element-index", selects those descendants that are array elements with the given index. the "..[<slice-index>]" form selects those descendants that are array elements selected by the given slice. the "..[<filter>]" form selects those descendants that are array elements or object values selected by the given filter. the "..[*]" and "..*" forms select all the descendants. An of the descendants of a node is a sequence of all the descendants in which: nodes of any array appear in array order, nodes appear immediately before all their descendants. This definition does not stipulate the order in which the children of an object appear, since JSON objects are unordered. The resultant nodelist of a "descendant-selector" applied to a node must be a sub-sequence of an array-sequenced preorder of the descendants of the node. </ins> 3.4.9.3. JSON: Queries: <ins> Note: The ordering of the results for the "$..[*]" and "$..*" examples above is not guaranteed, except that: "{"j": 1, "k": 2}" must appear before "1" and "2", "[5, 3, [{"j": 4}]]" must appear before "5", "3", and "[{"j": 4}]", "5" must appear before "3" which must appear before "[{"j": 4}]", "5" and "3" must appear before "{"j": 4}" and "4", "[{"j": 4}]" must appear before "{"j": 4}", and "{"j": 4}" must appear before "4". </ins> 3.5. Note that JSON "null" is treated the same as any other JSON value: it