The product plan calls for sequenced counters (or "levels"), and for the penalty for a revert to be for the count(s) for only the CURRENT counter to be reset to 0.
There are different ways of modeling this on the backend:
1) We could provide for counters to specify multiple target counts in an array, e.g., `[5, 50]`. (Implemented at https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/WikimediaEditorTasks/+/491292/)
* This raises some problems:
* If the first target (5) is passed, are only subsequent edits reset, or are all edits reset (but the record of passing 5 qualifying edits kept)?
* If so, since we are maintaining per-language counts, how do we decide which counts to reset for which languages, in a situation in which edits are distributed across languages? (I would prefer not to have to maintain full histories of qualifying edits for each user...)
2) We could otherwise provide for sequenced counters, and model multiple targets for edits with the same characteristics as separate counters.
* This would eliminate the issue of uncertainty over which particular count(s) to reset, but raises other issues:
* It could be confusing for clients.
* It requires some thought about what a valid chain or tree of sequenced counters should look like, and where/how validation should happen.
* It introduces more room for error in the counter configuration.
(Of course, these aren't mutually exclusive, and we might end up introducing both constructs anyway for different reasons.)
In either case, how do we make what's happening on revert minimally confusing to the user? On revert, is there a provision planned for the app to inform the user that (some or all of) the user's counted edits have been reset to 0, and why?