Your assessment of Scenario A is correct, in a failure condition such as an application or machine restart/process termination, when the process starts up again it will discover the undispatched commits and push them to the dispatcher.
Scenario B is somewhat more tricky. The issue is that the EventStore is not a bus so the question of how to handle errors in the bus isn't something that cannot be handled in the EventStore itself. Furthermore, because there are a number of bus implementations, I don't want to couple the EventStore to any particular implementation. Some users may not even use a message bus; they may decide to use RPC calls instead.
The question that you really have then is, how should bus failures--and by extension, queue failures--be handled? The EventStore has an interface IPublishCommits. When an event is committed it's then pushed to a dispatcher. The dispatchers are simply responsible for marking an event as dispatched once it has been properly and successfully handled by the implementation of IPublishCommits.
The best way to handle transient bus and queue failures would be to implement the circuit breaker pattern in your IPublishCommits implementation that retries until things start working again. For bigger issues, such as serialization failures, you may want to log some kind of critical failure that will notify an administrator immediately. Again, the sticky problem in all of this is that the EventStore cannot know about all of the specifics of your situation.
