anchor.diff:  a1 = b1 && a2 = b2 && ...
   ----
   
  -For clarity, we also repeat the current equality semantics of maps here (at the time of writing this CIP). Two maps `m1` and `m2` are considered equal if
  -
  -* `m1` and `m2` must have the same keys.
  -* For each key `k`,
  +For clarity, we also repeat the *current* equality semantics of maps here. Under these semantics, two maps `m1` and `m2` are considered equal if:
  +
  +* `m1` and `m2` have the same keys,
  +** including keys that map to a `null` value, and
  +** the order of keys as returned by `keys` does not matter.
  +* Additionally, for each such key `k`,
   ** either `m1.k = m2.k` is `true`,
   ** or both `m1.k IS NULL` and `m2.k IS NULL`
   
  -This is at odds with the common interpretation of `null` as standing for any possible value.
  -
  -It is aligned though with the most common use case for maps with `null` entries which is to update multiple properties at once, e.g. `SET n += { n: 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. Current equality semantics makes it easy to check if two maps correspond to the same property update in this scenario.
  -
  -However 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
  +This is at odds with the common interpretation of `null` as representing any possible value.
  +
  +However, the current map equality semantics is aligned with the most common use case for maps with `null` entries which is to update 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. Current equality semantics make it easy to check if two maps correspond to the same property update in this scenario.
  +
  +We note 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` => `null` if `expr1 IS null && expr2 IS NULL`
  -* `{a: expr1} = {a: expr2}` => `true` (!!) if `expr1 IS null && expr2 IS NULL`
  -
  -To fix this, we propose that two maps `m1` and `m2` instead should be equal if
  -
  -* `m1` and `m2` have the same keys (the order of keys as returned by `keys` does not matter)
  -* For each such key `k`, `m1.k = m2.k`
  +* `{a: expr1} = {a: expr2}` => `true` if `expr1 IS null && expr2 IS NULL`
  +
  +To rectify this, we propose instead that two maps `m1` and `m2` should be equal if:
  +
  +* `m1` and `m2` have the same keys,
  +** including keys that map to a `null` value, and
  +** the order of keys as returned by `keys` does not matter.
  +* Additionally, for each such key `k`,
  +** `m1.k = m2.k` is `true`.
   
   As a consequence of these changes, plain equality is not reflexive in a classic sense (Consider: `{a: null} = {a: null}`, `[null] = [null]`). However this was already the case (Consider: `null = null` => `null`).
   
  -However, Equality is reflexive for values that do not involve `null`.
  +However, equality is reflexive for values that do not involve `null`.
   
   === Equivalence ===
   
  
positive.code: 
  Equivalence is reflexive for all values.
  
  === Summary of Conceptual Model
  
  This proposal aims to simplify the conceptual model around equality, comparison, sorting, and grouping:
  
  * Equality: Equality follows natural, literal equality. However, values involving `null` are never equal. Nested structures are first tested for equality by shape (keys, size) and then componentwise. This ensures that equality is compatible with interpreting `null` as "unknown" or "could be any value".
  * Comparability: Comparability is aligned with equality. Two values of the same type in the global sort order are always comparable. Two values of different types are always incomparable and values involving `null` are always incomparable.
  This ensures that `MATCH (n) WHERE n.prop > 42` will never find nodes where `n.prop` is of type `STRING`.
  * Equivalence: Equivalence is a form of equality that treats `null` (and `NaN`) values as identical. Equivalence is used in grouping and `DISTINCT` where `null` commonly is interpreted as a marker that a value was missing instead of as a wildcard for any possible value.
  
negative.code: * Two `null` values are treated as the same value in accordance with the global sort order
  * Two `NaN` values are treated as the same value in accordance with the global sort order
  
  The accompanying descending global sort order is the same order in reverse (i.e. it runs from `VOID` to `NODE`).
  
  Any additional non-canonical types introduced by an implementation should be inserted between `PATH` and `MAP` in the global sort order. As an exception, any additional non-canonical number types may be integrated under the other types in the global sort order if they are of a very similar nature (e.g. other number-like types, or other string-like types).
  
  === Equality ===
  
  We propose that equality and comparability be aligned, i.e. `l = r` if and only if `l <= r && l >= r`.
  
  We thus unify the difference between equality and equivalence by making, by making lists containing `null` values follow the same difference as the `null` values themselves.
  
  Specifically, we propose to redefine how equality works for lists in Cypher.
  To determine if two lists `l1` and `l2` are equal, we propose two simple tests, as exemplified by the following:
  
  * `l1` and `l2` must have the same size, i.e. inversely `size(l1) <> size(l2>) => l1 <> l2`
  * the pairwise elements of both `l1` and `l2` must be equal, i.e.
  