For situations like this, I prefer what I call the "action lists" approach. It's a generalization of a technique that's been around in various forms for a very long time.
The basic implementation is that you have a queue of Action objects. An Action is something that takes time to complete. Each Action has an Update() method that can be called every iteration of the game state update loop, to perform any portion of the remaining work, and which can mark itself as being finished when the work is complete.
You can then keep this queue of Action objects, and call the Update() method for the Action in the front of the queue each frame. If the Action is marked as finished after it is run, it is removed the queue.
In your case, your ExplosionAction might start the explosion animation the first time its Update() is called. Each subsequence call to Update() would check if the animation is complete (and/or some other timer is complete), and if so, mark itself as finished.
You can then either wait for the action list to be emptied or you can create a SignalEventAction that is pushed onto the back of the queue after all the ExplosionAction objects. The SignalEventAction Update() method would call some callback function (or raise an event, if you have a more complete event system, as Byte56 suggested) and mark itself as finished. The end result will be that the explosions all fire, then the callback gets invoked to signal the game logic that all explosions are done. Nice and simple, and requires no explicit state tracking explosion counters or any special logic for the last explosion; this in turn makes the system a fair bit more robust, in my experience.
It can be helpful to put a small bit of state into the base Action implementation, such as flags whether the Action has already had its Update() method called once or not. You can then let derived implementations override specific callback methods like OnStart(), OnUpdate(), OnFinished(), etc.
There's quite a bit more you can do with an action list with very little extra implementation work. For your needs listed above, you should be fine with the most basic implementation.
If you're interested in more on the technique and how it can be applied to more complicated scheduling scenarios, see the following link to some PDF slides of an informal talk I did over the summer on it (the video is online too if you care to search for it, but it doesn't add anything over the slides): Action! Lists Slides (PDF)