anchor.diff:  
   However, this definition is aligned with the most common use case for maps with `null` entries: updating multiple properties through the use of a single `SET` clause, e.g. `SET n += { size: 12, remove_this_key: null }`. In this case, there is no need to differentiate between different `null` values, as `null` merely serves as a marker for keys to be removed (i.e. is a <<missing-null,"missing" `null` value>>). Current equality semantics make it easy to check if two maps would correspond to the same property update in this scenario. We note though that this type of update map comparison is rare and could be emulated using a more complex predicate. The current rules do however break symmetry with how equality handles `null` in all other cases. This becomes more apparent by considering these two examples:
   
  -* `expr1 = expr2` evaluates to `null` if `expr1 IS NULL && expr2 IS NULL`
  -* `{a: expr1} = {a: expr2}` evaluates to `true` if `expr1 IS NULL && expr2 IS NULL`
  +* `expr1 = expr2` evaluates to `null` if `expr1 IS NULL AND expr2 IS NULL`
  +* `{a: expr1} = {a: expr2}` evaluates to `true` if `expr1 IS NULL AND expr2 IS NULL`
   
   ====== New map equality ======
   
  
positive.code: 
  We propose that comparability and equality should be aligned with each other, i.e.
  
  `expr1 = expr2` if and only if `expr1 >= expr2 && expr1 \<= expr2`.
  
  Comparability and equality produce <<unknown-null,"unknown" `null` values>>.
  
  
negative.code: 
        p1 < p2
    <=> [n1, r1, n3] < [n1, r2, n2]
    <=> n1 < n1 OR (n1 = n1 AND [r1, n3] < [r2, n2])
    <=> false OR (true AND [r1, n3] < [r2, n2])
    <=> [r1, n3] < [r2, n2]
    <=> r1 < r2 OR (r1 = r2 AND n3 < n2)
    <=> true OR (false AND false)
    <=> true
  
    ** Paths are <<incomparable>> to any value that is not also a path.
  