Your assessment of scenario A is correct, in the event of a failure, for example, when the application / machine process is restarted / terminated, when the process starts again, it will detect unset commits and forward them to the dispatcher.
Scenario B is somewhat more complex. The problem is that the EventStore is not a bus, so the question of how to handle errors on the bus is not something that cannot be handled in the EventStore itself. In addition, since there are a number of bus implementations, I do not want to associate EventStore with any particular implementation. Some users may not even use the message bus; they can use RPC calls instead.
The question that you actually have is how to handle bus errors and, as a result, queue failures? EventStore has an IPublishCommits interface. When an event is committed, it then proceeds to the dispatcher. Dispatchers are simply responsible for marking the event as dispatched as soon as it has been correctly and successfully processed by the implementation of IPublishCommits.
The best way to handle bus busses and queue errors is to implement a circuit breaker pattern in your IPublishCommits implementation, which retries until everything starts working again. For large problems, such as serialization failures, you might want to register some kind of critical failure that will immediately notify the administrator. Again, the sticky problem in all of this is that EventStore cannot know about all the features of your situation.