Most of the stuff in that merge preview gets its data directly from the database (it's not like this is a millisecond performance-crictical section of the site); the only thing that is instead coming from a cache (our famous tag engine of doom) is getting the database ids of the tags you're merging. Since your previous merge changed the ids, the cached value and the database values were out of sync.
And since the tag merge is a silent operation (doesn't create revisions), the tag engine didn't notice it had to refresh the cache, which is why you still saw the old values even after an hour (I saw the correct ones because I hit a different server than you, where the cache was up-to-date; once I reloaded the cache for the server you were hitting, you saw the correct numbers as well).
One change I'll make is pull those ids from the database as well; the data we're using here should be up-to-date (note that this was only an issue in the preview; the actual tag merge always used current data). But we should also look to ensure that the tag engine is aware of the merge after it has happened.
Some of the above (regarding the tag engine) is guesswork, by the way; I'm anything but an expert on this part of our code*, so Marc may chime in and say "this is all wrong, stupid continental European".
* to be precise, I have no clue about its inner workings