"you have two messages"

I'm pretty sure that this phenomenon only affects people who
a) were registered before the event and
b) did not read the spam before Clinton manually removed it.
So it's not a problem for new users, only those who have been away from the Forge for a while and haven't noticed one of these regular question threads about the phenomenon.

The basic technical reason probably has to do with the forum infrastructure keeping tabs on unread messages in a different part of the database from where the messages themselves are stored. (Couldn't imagine a different way of doing it, anyway.) Clinton, again, would have destroyed the spam by manually checking the private message data table and removing all messages that the given registered user sent within the target timeframe. This would not affect the count of unread messages kept in a different table, which would then cause the phenomenon.

That is all pertinent mainly because I'm pretty sure that the only way to fix the problem would be to manually fix the user data tables that include the miscounted number of unread messages. I'm not personally familiar with particular SMF architecture, but it's quite likely that the number of unread messages is stored as a simple integer in a particular data field in the user data table, rather than a full hash table structure that'd track the unread status of individual messages. Considering this, the easiest way to remove the problem is to find the correct field in the user data table, verify that it doesn't indeed carry any other information, and then zero it for all users. A side-effect would be that everybody would then show zero unread messages whether they actually have new messages or not, but that wouldn't be a problem going forward, as the new message count would then match the actual messages in the person's mail box later on.

The one question mark in this purely theoretical plan is that I don't quite see why checking your new messages does not actually zero the counter for new messages, as it should if the number of new messages stored was actually just an independent number incremented when new messages arrive and zeroed when they are read; apparently some piece of code is actually checking the read-status of each message in the mailbox independently, and as it's not seeing the deleted messages, it's not decreasing the new message counter either. Perhaps this functionality is in place to handle several pages of new messages, in which case a user might not "see" all messages at once when they go to their mailbox. Other than that the SMF system loads and shows all new messages at once, so I don't see any other reason. Anyway, that kind of system would still be likely to be implemented with a specific counter field, so the only thing that really matters is finding that counter and zeroing it.

Of course not a matter of practical importance for me, either. Probably falls in the category of things that go away with the next forum update, whenever that will be.