anchor.diff:  RETURN x as column
   ----
   
  +=== Benefits to this proposal
   
  -=== Benefits to this proposal
   Explicit state change visibility makes it possible to understand queries without having to worry about ordering of updates and reads.
   
   From an implementation perspective, these semantics also allow us to make some queries more performant than they can be today, by ignoring statement state for a lot of graph reading, and saving us from eagerly producing matching results before updates can be applied.
  
positive.code: ----
  
  |===
  ||Pre-existing nodes|Rows in|Nodes created|Rows out
  |`MATCH ()`|2|1||2 (N)
  |`CREATE ()`|2|2|2 ( R ) |2
  |`WITH *`|4|2||2
  |`MATCH ()`|4|2||8 (N * R)
  |`CREATE ()`|4|8|8|8
  |_Outcome_|*12 (2+2+8)*||*10*|*8*
  |===
  
  .Example query 3:
  In the following query, the +MATCH+ following the +UNION+ will find the nodes created before the +UNION+.
  
  [source,cypher]
  ----
  
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]
  