anchor.diff:  
   We propose that <<orderability-def>> and <<equivalence-def>> should be aligned with each other, i.e.
   
  -`expr1` is equivalent to `expr2` if and only if they have the same position under orderability (i.e. they would be sorted before (or after resp.) any other non-equivalent value in the same way).
  +`expr1` is equivalent to `expr2` if and only if they have the same position under orderability (i.e. they would be sorted before (or after respectively) any other non-equivalent value in the same way).
   
   Orderability and equivalence produce <<missing-null,"missing" `null` values>>.
   
  
positive.code: 
  - <<comparability-equality,Comparability and equality>> are aligned with each other
    * <<equality-con,Equality>> follows natural, literal equality. However, values involving `null` are never equal to any other value. Nested structures are first tested for equality by shape (keys, size) and then their corresponding elements are tested for equality pairwise. This ensures that equality is compatible with interpreting `null` as "unknown" or "could be any value".
    * <<comparability-con,Comparability>> ensure that any two values of the same leaf type in the <<global-sort-order>> are comparable.
    Two values of different types are incomparable and values involving `null` are incomparable, too.
    This ensures that `MATCH (n) WHERE n.prop < 42` will never find nodes where `n.prop` is of type `STRING`.
  - <<orderability-equivalence>> are aligned with each other
    * <<equivalence-con,Equivalence>> is a form of equality that treats `null` (and `NaN`) values as the same value. Equivalence is used in grouping and `DISTINCT` where `null` commonly is interpreted as a category marker for results with missing values instead of as a wildcard for any possible value.
    * <<orderability-con,Orderability>> follows comparability but additionally defines a <<global-sort-order>> between values of different types and is aligned with equivalence instead of equality, i.e. treats two `null` (resp. `NaN`) values as equivalent.
  - Aggregation functions that rely on notions of sameness and sorting are aligned with equivalence and orderability.
  
  [[examples]]
  
negative.code: == Benefits to this proposal
  
  A consistent set of rules is defined for <<equality-con,equality>>, <<equivalence-con,equivalence>>, <<comparability-con,comparability>> and <<orderability-con,orderability>>.
  
  Futhermore, aggregation semantics are clarified and this proposal prepares the replacement (or reinterpretation) of `NaN` values as `null` values in the future.
  
  == Caveats to this proposal
  
  Adopting this proposal may break some queries; specifically queries that depend on equality semantics of lists containing `null` values.
  It should be noted that we expect that most lists used in queries are constructed using `collect()`, which never outputs `null` values.
  
  This proposal changes path equality in subtle ways, namely loops track the direction in which they are traversed.
  It may be helpful to add a path normalization function or path to entities conversion function in the future that allows to transform a path in a way that removes this semantic distinction.
  
  == Appendix: Comparability by Type
  
  The following table captures which types may be compared with each other such that the outcome is either `true` or `false`.
  Any other comparison will always yield  a`null` value (except when comparing `NaN` values which are handled as described above).
  
  .Comparability of values of different types (`X` means the result of comparison will always return `true` or `false`)
  [frame="topbot",options="header,footer"]
  