Hello, yes that is correct since for a CollectionTagger (which is what the indicators use), the TagsChanged only fires if you call into the indicator (or lower level tagger) API to alter the collection. The TagsChanged event doesn't fire in the case where a text deletion occurs that ends up removing tags since we actually don't detect that scenario until tags for that deleted range are collected (such as by a UI refresh for that range). Normally if you delete text that contains an indicator, the UI is already being refreshed over that range, so if we fired another TagsChanged event then it would trigger another UI refresh that is unnecessary, thereby degrading performance.
I agree that this is a bit of an inconsistent scenario. We have to consider that collection taggers work a bit different from other taggers though. In collection taggers, we are holding a fixed list of tags. In other taggers, they are completely virtualized, and only do tag lookups on demand to improve performance.
We don't have any events for when the tagged regions "translate" to new snapshots, which may or may not slide them around the document depending on the text change between snapshots. That translation also only occurs on demand, when the tags are requested.
To work around the issues here, what if you did something where you had a separate list of breakpoints and their ranges. Then you handle TagsChanged like now but also the DocumentTextChanged event. In both handlers you get the breakpoints again, and see if any have changed (added, removed or translated). I think by doing that, you would get all the notifications you need.