anchor.diff:  * Let `AGGR(_L_)` be `AGGR(_p_~1~), AGGR(_p_~2~), ..., AGGR(_p~N~_)`, and
   * Let `POST_PROJ(_L_)` be `POST_PROJ(_p_~1~), POST_PROJ(_p_~2~), ..., POST_PROJ(_p~N~_)`.
   
  -With this the semantics of `RETURN _L_` can be defined as effectively equivalent to
  +[IMPORTANT]
  +.Rewrite semantics
  +====
  +`RETURN _L_` is effectively equivalent to
   
   [source, cypher, subs="quotes"]
   ----
  
positive.code: RETURN AGGR(_L_)
  ----
  
  Analogously, the semantics of `WITH _L_` can be defined as effectively equivalent to
  
  [source, cypher, subs="quotes"]
  ----
  
negative.code: ==== Syntax restriction
  
  The rewrite does not cover all syntactically possible queries.
  Specifically, any <ProjectItems> containing
  
  * an aggregation function and
  * a sub-expression that is
  ** outside any contained aggregation function and
  ** not constant under the grouping keys
  
  is not rewritten to valid query.
  
  .Aggregation *not* covered by the rewrite
  ====
  
  By the grouping and aggregation semantics, the RETURN clause
  
  .[[Q6]]Q6
  [source, cypher]
  