Besides individual token hierarchy events it would be useful to provide aggregated changes too. It would be useful for
incremental parser-like tools that need to fix their structures based on lexical changes but that do not want to do that
after every document modification.
The only requested chunking of the aggregation so far (and imho the most reasonable) were the atomic document edits
(i.e. NbDocument.runAtomic() transactions) which cover e.g. code reformatting and the common document edits.

Technically the lexer would provide
TokenHierarchy.add/removeAggregatedTokenHierarchyListener(TokenHierarchyListener)

The fired event would contain a union of all the relexed regions from the individual changes. If two regions would be
far enough from each other so that there would be some unchanged tokens then these unchanged tokens would be reported as
removed (by TokenChange.removedTokenSequence()) and re-added (they would be present in
TokenChange.currentTokenSequence()). Although in practice the changes that would not be adjacent are rare the tools
could get a fine-grained info by checking Token.isRemoved() (result of an issue 122786) on the tokens returned by 
TC.removedTS() to find out whether a particular token was really removed or if it was amidst of two non-adjacent
modifications.

In practice most of the clients can possibly use aggregated token hierarchy listening rather than regular grained
listening. For example syntax higlighting will not be rendered until the document is read-lockable and it only needs to
know the affected region of the token modifications so it would be fine to use the aggregated listening. There could be
a boolean parameter collectRemovedTokens added to TH.addAggregatedTHL() to possibly omit collecting of the removed
tokens if there would be no client requesting that (e.g. the syntax highlighting client is not interested in that
information).