Change:
Editorial improvements Correct != comparison involving at least one empty nodelist.
I'm not sure that is so obviously false, so maybe mentioning that a structured value on one side spoils the comparison may be needed.
Ok, I can see how someone might read that into the spec. I'll add something.
Please see the comparison examples I just added. These should help to draw out the implications of the semantics.

Discussion:
element or member value as the filter selector iterates over the array or object. <ins> 3.4.8.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 <del> path does not select a node.  To be more specific about the actual value of a node selected by a path, explicit comparisons are necessary.  This existence test -- as an exception to the general rule -- also works with nodes with structured values. </del> <ins> path does not select a node.  This existence test -- as an exception to the general rule -- also works with nodes with structured values. To test the value of a node selected by a path, an explicit comparison is necessary.  For example, to test whether the node selected by the path "@.foo" has the value "null", use "@.foo == null" (see null-semantics) rather than the negated existence test "!@.foo" (which yields false if "@.foo" selects a node, regardless of the node's value). 3.4.8.2.2. </ins> When a path resulting in an empty nodelist appears on either side of <del> a comparison, the comparison yields true if and only if the comparison operator is "==", ">=" or "<=" and the other side of the comparison is also a path resulting in an empty nodelist. </del> <ins> a comparison, the comparison yields true if and only if: the comparison operator is "==", ">=" or "<=" and the other side of the comparison is also a path resulting in an empty nodelist, or </ins> <del> When no path resulting in an empty nodelist appears on either side of a comparison, any path which appears on either side of the comparison and results in a nodelist consisting of a single node is replaced by the value of the node and then: </del> <ins> the comparison operator is "!=" and the other side of the comparison is not also a path resulting in an empty nodelist. </ins> <del> comparison using one of the operators "==" or "!=" yields true if and only if the comparison is between: </del> <ins> When any path on either side of a comparison results in a nodelist consisting of a single node, each such path is replaced by the value of its node and then: </ins> <del> primitive values which satisfy the comparison, or </del> <ins> comparison using one of the operators "==" yields true if and only if the comparison is between equal primitive values. </ins> <del> structured values compared using "!=". </del> <ins> comparisons using one of the operators "<=" or ">=" yield true if and only if the comparison is between numeric values which satisfy the comparison. </ins> <del> comparisons using one of the operators "<", "<=", ">", or ">=" yield true if and only if the comparison is between numeric values which satisfy the comparison. </del> <ins> any comparison of two values using one of the operators "!=", ">", "<" is defined as the negation of the comparison of the same values using the operator "==", "<=", ">=", respectively. </ins> <del> Note that comparisons between structured values, even if the values are equal, yield false. </del> <ins> Note that "==" comparisons between a structured value and any value, including the same structured value, yield false.  Consequently, "!=" comparisons between a structured value and any value, including the same structured value, yield true. </ins> <del> Data types are not implicitly converted in comparisons.  So "13 == '13'" yields false. </del> <ins> 3.4.8.2.2.1. JSON: 3.4.8.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.8.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 "R" are any expressions with syntax "logical-and-expr", "T" is any