Initially we thought that we wanted to support different invocation modes for listeners (T379775), at least a "deferred" (after-commit) mode and an "immediate" (before-commit) mode, plus perhaps an "asynchronous" (in-job) mode (T384609).

However, it seems like we really only want to support defferred (after-commit) execution of listeners. The two other modes were removed for the following reasons:

• Synchronous (before-commit) execution makes allows listeners to interfere with the ongoing transaction. It is more convenient for the emitter to have guaranteed "fire and forget" semantics. If it turns out that there are some use cases that abolsutely need to be able to fail the main transaction if something goes wrong, we can add a way for the emitter to opt into allowing synchronous dispatch.
• Asynchronous (in-job) execution is useful, but scheduling a job for every listener on every event is wasteful. We want to give the listener a chance to decide whether the expensive logic is actually needed before scheduling the job (T387010).

For this reson, the facilities for supporting multiple invocation modes should be removed for now. This also means that the names of listener methods on subclasses of EventSubscriberBase should no longer include an invocation mode as a suffix. However, the "AfterCommit" suffix needs to be supported for a while to avoid breaking production.