Change:
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 ("$"),

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