The product plan calls for sequenced counters (or "levels"), and for the penalty for a revert to be for the count(s) for the CURRENT counter only 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 qualifiying edits for each user...)
2) We could otherwise provide for sequenced counters, and model two multiple targets for edits with the same characteristics as two separate counters.
* This would eliminate the issue of uncertainty over which 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.
* 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 minimally confusing to the user? On revert, is there a provision planned to inform that (some or all of) the user's counted edits have been reset to 0, and why?