Generally when usability literature turns to the subject of error messages it concentrates on the physical manifestation of the error message rather than why the message happened at that point in the interaction (in application terms, the validation of the business rule). For example, usability experts often tell us to write helpful messages, not to scare the user with outrageous text and graphics, make the error message appear close to the problem area in the UI, and so on. Fair enough.
But, stopping just there, is for me a clue to one of the reasons error messages can be so annoying - they're more disruptive to the natural flow of a task than they should be. Really designers need to pay attention to how people work and design the validation points around that.
For example, why design the input of data in fields across a series of tabs with the intention of validating all together at the end with a final submission (Scenario B)? It's a nightmare for users to then go back across the tabs, and revalidate fields on each tab. Instead, why not validate each tab's field data progressively as you go (Scenario B)? Makes much more sense from an interaction and productivity perspective.
Remember, error messages are there to support the user, not frustrate them further, so reduce the user's memory load by requiring them to go back a few steps and recommit data.
Users want to commit correct data right way in a natural flow, not just complete fields for the sake of it. Granted, there can be some technical issues about committing data for validation that you may need to work on, but when designing messages start out by looking at a) how users work and then b) relating that to how your application validates data.
Of course, you may have a different idea. I'd love to hear it!