anchor.diff:  
   === Equality ===
   
  -Finally, we propose that equality and comparability must be aligned, i.e. `l = r <=> l <= r && l >= r`.
  +We propose that equality and comparability must be aligned, i.e. `l = r` if and only if `l <= r && l >= r`.
   
   To achieve this, we unify the difference between equality and equivalence, by making lists containing `null` values follow the same difference as the `null` values themselves.
  +
   Concretely, we propose to redefine how equality works for lists in Cypher today.
   To determine if two lists `l1` and `l2` are equal, we propose two simple tests, like so
   
  
positive.code: * Booleans are compared such that `false < true`.
  * 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]`.
  * Maps are compared as if they where lists of lists, where the inner lists are the key-value pairs of the maps, ordered in ascending sort order for the keys and omitting map entries where the value is `null`. Comparing a map to a value that is not a map always 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 kind 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 where 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`.
  
negative.code: === Orderability
  
  We further propose that orderability be defined between any pair of values, where the result is always `true` or `false`; i.e. always defined.
  To accomplish this, there must be a pre-determined type order and each value must fall under exactly one type in this order. We propose to use the following ascending global sort order of types:
  
  * `NODE`
  * `RELATIONSHIP`
  