The content of this issue doesn't really fit the template so I'm just going to freestyle here, if it's not a problem.

I'm going to make a short introduction just to make sure I fully unsrtand how the dispatching system currently works:

The current updates dispatching system allows to use different groups of handlers. Every update is dispatched sequentially to each handler of each group. If the update passes an handler's checks, the handler's callback is executed and the update is dispatched to the handlers of the following group.

I'm not completely sure what I'm going to request is a good design choice, but I've more than once found myself in this situation: because of some processing needs, I sometimes have to define many different handlers which run some logging/debugging/filtering/editing/flood control/db operations that need to be done on every update received by the bot, and every update needs to enter these handlers regardless of what happened in the previous handlers.
Right now, I'm structuring my handlers in a way each of these "preprocess" handlers is registered in a different group, using the group parameter of dispatcher.add_handler().

This structure, by the way, it's hard to mantain because each handler needs to be registered in a different group. Adding a new handler requires a lookup of the files containing the callbacks to figure out what's the highest/lowest group used until now.

So, after this premise, my request is: it would be nice to be able to raise an exception that signals the dispatcher to continue the propagation of the current update to the next handler of the current group, in a similar way to what we can already do with DispatcherHandlerStop to stop the propagation

I'm aware my proposal of raising an exception to continue the propagation inside the current group doesn't really sound as a good design choice, but it would match the already established opposite behavior