anchor.diff:  
   .Example query 2:
   
  -Given a database containing two nodes, and the following query,
  -the sequence below describes a non-obvious query execution.
  +Given a database containing two nodes, and the following query, the sequence below describes a non-obvious query execution.
   
   [source,cypher]
   ----
  
positive.code: toc::[]
  
  === Background
  Cypher allows queries to go through multiple steps, and it’s possible to interleave reading and writing to the graph.
  Some clauses can also do both - read the graph and write to it at the same time.
  
  To allow the user to understand what the outcome will be at an abstract, logical level, semantics for the visibility of these changes should be clear.
  
negative.code: This is not about concurrency - even in a single user system this would need to be thought through and defined explicitly.
  
  === Proposal
  
  Each clause lives in its own state, which includes all the changes of clauses coming before it, including changes performed by itself,
  *but none of the changes made by clauses listed later in the query.*
  
  The semantical data flow here is such that each clause operates on the entire result set before passing control to any subsequent clause.
  
  Updates between `UNION` subqueries are also treated in a sequential manner.
  Therefore subqueries coming later will see updates from subqueries before, but not the other way around.
  
  ==== Examples
  
  .Example query 1:
  The following query would lead to a never-ending loop, if a lazy `MATCH` clause is not isolated from the new nodes created by `CREATE`.
  
  _Query_
  [source,cypher]
  