Change:
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.

Discussion:
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!