Original text:
The well-formedness and the validity of JSONPath queries are independent of the JSON value the query is applied to; no further <del> errors can be raised during application of the query to a value. </del>  Obviously, an implementation can still fail when executing a JSONPath query, e.g., because of resource depletion, but this is not modeled what happens if a JSON text does not represent valid JSON are not defined by this specification.  3.2. Syntactically, a JSONPath query consists of a root selector ("$"), 3.4.2.2. The "dot-selector" selects the node of the member value corresponding <del> to the member name from any JSON object in its input nodelist.  It selects no nodes from any other JSON value. </del>  3.4.2.3. A "dot-wild-selector" acts as a wildcard by selecting the nodes of all member values of an object in its input nodelist as well as all <del> element nodes of an array in its input nodelist.  Applying the "dot- wild-selector" to a primitive JSON value (a number, a string, "true", "false", or "null") selects no node. </del>  3.4.3.3. The "index-selector" applied with a "quoted-member-name" to an object selects the node of the corresponding member value from it, if and <del> only if that object has a member with that name.  Nothing is selected </del>  from a value that is not a object. The "index-selector" applied with an "element-index" to an array 3.4.5.2. An "index-wild-selector" selects the nodes of all member values of an <del> object as well as of all elements of an array.  Applying the "index- wild-selector" to a primitive JSON value (that is, a number, a string, "true", "false", or "null") selects no node. </del>  The "index-wild-selector" behaves identically to the "dot-wild- selector". or <del> of their array elements or member values, respectively.  Applied to other value types, it will select nothing. </del>  A relative path, beginning with "@", refers to the current array element or member value as the filter selector iterates over the and "null") which are equal, equal arrays, that is arrays of the same length where each <del> element of the first array yields true when compared using "==" to the corresponding element of the second array, or </del>  <del> equal objects, that is objects where: </del>  <del> for each member of the first object with name "n" and value "v", there is a member of the second object with name "n" and value "w" where "v" and "w" yield true when compared using "==", and </del>  <del> for each member of the second object with name "n" and value "v", there is a member of the first object with name "n" and value "w" where "v" and "w" yield true when compared using "==". </del>  a comparison using the operator "!=" yields true if and only if the comparison is not between equal values of the same type. 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.

Reviewer comments:
According to the current draft certain types, such as Booleans, are unordered: equality () and inequality () of values of these types are specified ordered comparisons (, , , and ) are specified to yield false for values of these types. However, is often understood the way it is read: "less than or equal to". Similarly for . If we could define as " or " and as " or ", then they could be easier to understand. With this change , for example, would yield true (whereas according to the current draft, it yields false). There is often an assumption that orderings are "total" or "linear" (see wikipedia for a ). A total order obeys the following laws: But according to the current draft, for example, and both yield false, contrary to the first of the above laws. This is because the ordering of Boolean values is not_ total. In the discussion at today's interim meeting (2022-08-17), it was suggested that the above laws could cause a problem for this issue. This does not appear to be the case because we are not dealing with total orders.
The above section about = is phrased in terms of total orders; I believe this is a POLS violation as most people will not think in terms of total orders here.
NAME Ok. That section isn't necessary: I was merely trying to capture the concern you expressed in the meeting. Please could you explain your concern with the above proposal (ignoring the "Total orders" section)?
Note to self: to avoid delta clashes, I intend to wait for the following PRs to land or close before submitting a PR for this issue: [x] URL [x] URL
Note to self (and anyone else who finds mathematics helpful)... With the proposed change, for all including when is "absent", an object, an array, a boolean, or . Apart from that is just as in the current draft. Similarly for which can be dealt with similarly. The ordering in the current draft is almost a partial order. That is, the following are true for all , , : except that the reflexive axiom is not true if or are "absent", an object, an array, a boolean, or . When restricted to numbers or restricted to strings is a total order. That is if and are both numbers or both strings, then in addition to the partial order axioms, the following is true: Note: is not a total order when restricted to arrays (if we decide to support for arrays), since, for example: The ordering in the current draft is a strict partial order: The of defines in terms of_ : The result is the same as in the current draft except that for all . So, for example, (where is "absent", since ), , and (where and are objects for which ). So is a partial order (without exception) and is still a total order when restricted to numbers or when restricted to strings.
NB. if URL lands, is false, but with the above proposal it would be true.

Revised text:
The well-formedness and the validity of JSONPath queries are independent of the JSON value the query is applied to; no further  <ins> errors relating to the well-formedness and the validity of a JSONPath query can be raised during application of the query to a value. </ins> Obviously, an implementation can still fail when executing a JSONPath query, e.g., because of resource depletion, but this is not modeled what happens if a JSON text does not represent valid JSON are not defined by this specification. <ins> When a JSONPath query is applied to a JSON value containing an object with duplicate names, the behaviour is unpredictable.  (Such a value usually originates in JSON text containing an object with duplicate keys, but how such a value could be constructed depends on how the JSON text is parsed and how the parsed value is represented.) </ins> 3.2. Syntactically, a JSONPath query consists of a root selector ("$"), 3.4.2.2. The "dot-selector" selects the node of the member value corresponding  <ins> to the member name from any JSON object in its input nodelist.  The behaviour is unpredictable if the JSON object has duplicate names. It selects no nodes from any other JSON value. </ins> 3.4.2.3. A "dot-wild-selector" acts as a wildcard by selecting the nodes of all member values of an object in its input nodelist as well as all  <ins> element nodes of an array in its input nodelist.  The behaviour is unpredictable for an object with duplicate names. Applying the "dot-wild-selector" to a primitive JSON value (a number, a string, "true", "false", or "null") selects no node. </ins> 3.4.3.3. The "index-selector" applied with a "quoted-member-name" to an object selects the node of the corresponding member value from it, if and  <ins> only if that object has a member with that name.  The behaviour is unpredictable if the object has duplicate names.  Nothing is selected </ins> from a value that is not a object. The "index-selector" applied with an "element-index" to an array 3.4.5.2. An "index-wild-selector" selects the nodes of all member values of an  <ins> object as well as of all elements of an array.  The behaviour is unpredictable for an object with duplicate names. Applying the "index-wild-selector" to a primitive JSON value (that is, a number, a string, "true", "false", or "null") selects no node. </ins> The "index-wild-selector" behaves identically to the "dot-wild- selector". or  <ins> of their array elements or member values, respectively.  The behaviour is unpredictable for objects with duplicate names.  Applied to other value types, it will select nothing. </ins> A relative path, beginning with "@", refers to the current array element or member value as the filter selector iterates over the and "null") which are equal, equal arrays, that is arrays of the same length where each  <ins> element of the first array is equal to the corresponding element of the second array, or </ins>  <ins> equal objects with no duplicate names, that is where: </ins>  <ins> both objects have the same collection of names (with no duplicates), and </ins>  <ins> for each of those names, the values associated with the name by the objects are equal. </ins> a comparison using the operator "!=" yields true if and only if the comparison is not between equal values of the same type. This definition does not stipulate the order in which the children of an object appear, since JSON objects are unordered. <ins> The behaviour of a "descendant-selector" is unpredictable if the node or one of its descendants is an object with duplicate names. </ins> 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.