List 1 is a monthly newsletter. An email is sent early in the month, every month, and no other traffic. If we want to allow subscribers to bounce once and only on the second bounce (because it was just a transitory issue) you need a second bounce, then at least for email from this list, you need 2 bounces (and likely don't want more) and need something like 45 days between bounces to reset the count.
List 2 is much more active, many messages a day, and some ISP will occasionally bounce a message with a spam false alarm. If we used the same settings as above, many people would get disabled for the false alarm spam. You can change the reset parameter to reset if you get just one day without a bounce, as that meant messages did get through, and you likely want the threshold higher, something like 4-7 bounces to give people a chance to clear issues, or just not get hit when you get a couple of false alarms in a row.
We can tackle this by keeping different attributes for each mailing list object ( which is there in my proposal ). The problem arises when an email is subscribed to both. Here we can keep the bounce score different ( mailing list email pair ) and disable only the subscription to list 2.
Unless Mailman could somehow keep track of successfully sent messages, and be able to use that in the rules, it is hard to see how to deal with both lists with a common counter. And keeping track of success can be hard, as some systems will accept the message, and later return the rejection message (this does have back-scatter issues, but it is done), and the delay can be significant (I've seen rejects days later for some system issues).
Not necessarily I suppose, keeping in track of bounces in (mailing list, email ) pair will do mostly do. But then again what Mark points out regarding complexity and bugs is definitely a point to consider.