anchor.diff:  
   [NOTE]
   ====
  -A less artificial example is calculating the total gross of an order as the discounted sum of line item net values (product price multiplied by amount) in query such as:
  +A less artificial example is calculating the total gross of an order as the discounted sum of the net values –– product price multiplied by amount –– of the order's line items in query such as:
   
   .[[Q5]]Q5
   [source, cypher]
   ----
   MATCH
  -(c:Customer)-[:LOCATED_IN]->(s:State)
  -(c)-[:ORDERED]->(o:Order)
  +(c:Customer)-[:LOCATED_IN]->(s:State),
  +(c)-[:ORDERED]->(o:Order),
   (o)-[:INCLUDES]->(li:LineItem)-->(p:Product)
   RETURN s AS state, c AS customer, o AS order,
  -       SUM(li.amount * p.price) * c.discount * j.vat AS totalGross
  -----
  -====
  -
  -It has been documented on multiple occasions (e.g. cf. http://opencypher.org/articles/2017/07/27/ocig1-aggregations-article/[First oCIG Meeting]) the existing semantics or Cypher is imprecise on such queries.
  +       SUM(li.amount * p.price) * c.discount * s.vat AS totalGross
  +----
  +====
  +
  +It has been documented on multiple occasions (e.g. cf. http://opencypher.org/articles/2017/07/27/ocig1-aggregations-article/[First oCIG Meeting]) that the existing semantics of Cypher is imprecise on such queries.
   
   A precise semantics on such queries has to provide
   
   * A clear definition which <ProjectionItem>s constitute the grouping keys
  -* Clear rules for which sub-expressions are allowed in <ProjectionItem>s containing aggregation functions
  +* Clear rules which sub-expressions are allowed in <ProjectionItem>s containing aggregation functions
   
   This proposal provides a such precise semantics.
   
  
positive.code: WITH AGGR(_L_)
  ----
  
  Let's call this the _simple rewrite semantics_ for the WITH and RETURN clause.
  
  .Simple rewrite semantics
  ====
  
negative.code: |===
  ====
  
  The semantics of such RETURN and WITH clauses can be described as a rewrite to the two baseline semantics combined by Cypher's linear composition.
  
  For this purpose, the <ProjectionItem>s in _L_ can be spilt into _aggregates_ and _grouping keys_:
  
  * A <ProjectionItem> _p_ is an aggregate if it is of the form `_agg_(_ex_) AS _al_`, where
  ** _agg_ is an aggregation function,
  ** _ex_ is an expression, and
  ** _al_ is an alias; and
  * A <ProjectionItem> _p_ is a grouping key if is not an aggregate
  
  For a <ProjectionItem> _p_,
  
  * If _p_ is a grouping key of the form `_ex_ AS _al_`
  ** Let `PROJ(_p_)` be `_ex_ AS _al_` and
  ** Let `AGGR(_p_)` be `_al_ AS _al_`
  * If _p_ is an aggregate of the form `_agg_(_ex_) AS _al_`
  ** Let `PROJ(_p_)` be `_ex_ AS _al_` and
  ** Let `AGGR(_p_)` be `_agg_(_al_) AS _al_`
  
  Further, for a set of <ProjectionItem>s _L_ = {_p_~1~, _p_~2~, ... _p~N~_},
  