Yep, that's right. That's a difficult spot for sounds, and the intention is that when something happens that triggers a sound event, multiple sounds should not play at the same time if more than one sound event is triggered by whatever happened.
When someone busts out, there is the potential to trigger a multitude of sound events: player busts out, player busts out Nth, player busts out with rank N, player busts out on the bubble, player busts out in the money, player rebuys, tables are unbalanced, the tournament ends. 2.0 had a bug in that those sounds could overlap. Say, for example, you busted out a player and the player chose to rebuy immediately. If you had sound events defined for players busting out and for players rebuying, both played at the same time.
So, now the software has to wait until it has enough information about what's going on before it can decide what sound to play. If the tables were unbalanced and a sound was played for it (tables being unbalanced), the software won't play a sound for a player busting out. And it doesn't know if a sound played for the tables being unbalanced until the user closes the dialog.
I think for that specific case, it might be possible to look ahead and see if a sound is going to play for tables being unbalanced, and go ahead and play a sound for a player busting out if not. I'll look into it.