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: * Strings are compared in dictionary order, i.e. characters are compared pairwise in order and characters missing in a shorter string are considered to be smaller than any other character. For example, `'a' < 'aa'`.
  * Lists are compared in dictionary order, i.e. list elements are compared pairwise in order and elements missing in a shorter list are considered to be smaller than any other value. For example, `[1] < [1,0]`.
  * Lists containing `null` values are incomparable, i.e. comparing them with any other value yields `null`.
  * Maps are compared as if they were lists of lists, where the inner lists are the key-value pairs of the maps, ordered in ascending sort order for the keys. Comparing a map to a value that is not a map always yields `null`.
  * Maps containing explicit `null` value entries are incomparable, i.e. comparing them with any other value yields `null`.
  * The comparison order for nodes (and relationships resp.) is undefined, and an implementation may choose an order for these freely, e.g. by using some sort of id. This order must not change during the execution of the query (i.e. it must be stable in the presence of updates). Comparing a node to a relationship always yields `null`.
  * Paths are compared as if they were a list of alternating nodes and relationships of the path from the start node to the end node. Comparing a path to a value that is not a path always yields `null`.
  * Implementations may choose to define suitable comparability rules for values of additional, non-canonical types. However comparing a value of an additional, non-canonical type to any of the canonical types always yields `null`.
  * Comparing any kind of value not covered above to an arbitrary other value, always yields `null`. This includes comparing a non-`null` value to a `null` value.
  
  