Currently, throttle parameters (found in abuse_filter_action->afa_parameters and abuse_filter_history->afh_actions) are in the form

[ filterID, "count,period", ...groups ]

This is extremely awkward, for two good reasons:

1. It stores the filter ID, which is already stored in the row (afa_filter for abuse_filter_consequences); it'll be used when checking if a user must be throttled to build the throttle key, but it's enough to retrieve it from afa_filter at runtime.
2. Count and period are stored together. I don't really know the reason for it, but it's a highly risky way of storing two separate NUMERIC values. What if the user adds a comma to one of the two? When we split the string we end up with completely wrong numbers. And no, there's currently no validation on the fields, so commas CAN be added. This patch will help with validation, although I guess commas will have to be treated separately (see below).

My proposal is to first merge the patch linked above, run the script and think about T203359 (i.e. deprecate old stuff). Then, what should we do with values with a comma inside? Before adding validation (or right after) we'd need to identify them and emit well visible errors, so that they can be fixed (which is something we'd better not do automatically). Then, we should merge the patch which I'll send in a minute in order to rewrite throttle parameters. The proposed form is:

[ count, period, ...groups ]

which should make much more sense. The patch is backward compatible and adds another maintenance script to rewrite DB tables. Then again, we should add deprecation for old-type parameters and eventually remove all the old code.
The whole operation must be well coordinated, and as I envisioned it, it'll take at least a major MW version or two to be fully completed.