This has evolved with the realization that the Framework ought to support protecting indices, since the remove / addback operation is potentially complex, and optimizable. Complex: the remove must be over all views where the item may be indexed; the remove can exclude bag indices (because they have no keys), and if allow-multiple-add-to-indices are allowed, a count needs to be maintained when removing and used when adding back (and multiple removes need to happen, until all identical instances are removed). optimizable - the remove only needs to be done if the FS is in the index, and we can cache the fact it's not in the index which covers the most common cases; and the remove and add can skip bag indices.
Support for this is in
UIMA-4135. Instead of throwing exceptions, the check would be better if it operated in "automatic" mode - where it automatically does the right remove/addback operation, and (optionally) gives a report.
This design would have the following modes:
1) high performance - no runtime-checks for corruption, as was the case prior to 2.7.0. But the user could implement protectIndices blocks or try-finally blocks to do the optimized remove/addbacks.
2) automatic, with or without reporting. This would replace the earlier design of this Jira, so instead of throwing an exception, it would report a Warning, and then proceed to automatically "handle" it. Users not concerned with high performance could run with this mode without reporting. Users concerned with high performance would get the report, implement their own "fixes" to the reported issues (including implementing protectIndices blocks / try - finally blocks around the reported spots), and then, run in #1 high performance mode.
Users running with automatic and with their own protectIndices blocks or try-finally blocks might be "rechecking" their pipeline to see if other things have crept in. To make this work, automatic would be "turned off" within a protected area.