anchor.diff:  g.V().repeat(both()).times(1000000).emit().range(6,10)
   ----
   
  -The `range()`-step can also be applied with `Scope.local`, in which case it operates on the incoming collection.  For example, you can produce a `Map<String, String>` for each traversed path, but containing only the second property value (the "b" step).
  +The `range()`-step can also be applied with `Scope.local`, in which case it operates on the incoming collection.  For example, it is possible to produce a `Map<String, String>` for each traversed path, but containing only the second property value (the "b" step).
   
   [gremlin-groovy,modern]
   ----
  
positive.code: g.E().drop()
  ----
  
  The example above uses TinkerGraph which does not support transactions.  As mentioned previously, for these types of graph implementations events are raised as they occur within execution of a `Step`.  As such, the final line of Gremlin execution that drops all edges shows a bit of an inconsistent count, where the removed edge count is accounted for after the event is raised.
  
  CAUTION: `EventStrategy` is not meant for usage in tracking global mutations across separate processes.  In other words, an mutation in what JVM process is not raised as an event in a different JVM process.  In addition, events are not raised when mutations occur outside of the `Traversal` context.
  
  PartitionStrategy
  ~~~~~~~~~~~~~~~~~
  
negative.code: EventStrategy
  ~~~~~~~~~~~~~
  
  The purpose of the `EventStrategy` is to raise events to one or more `MutationListener` objects as changes to the underlying `Graph` occur within a `Traversal`. Such a strategy is useful for logging changes, triggering certain actions based on change, or any application that needs notification of some mutating operation during a `Traversal`.  If the transaction is rolled back, the event queue is reset.
  
  The following events are raised to the `MutationListener`:
  
  