Of course, I defer judgement to the dev team, but I'd be remiss if I didn't reflect the implications of this behavior:

When this behavior is implemented, it will effectively split all class decorators into one of three categories:

1. ABC-agnostic, who don't consider abstract superclasses as a use case. total_ordering will be of this category.
2. ABC-aware, subclass-agnostic, who accept the possibility of an abstract superclass, and thus call update_abstractmethods. dataclass will be of this of this category, as well as, update_abstractmethods, techinally.
3. ABC-aware, subclass-aware, who accept the possibility of an abstract superclass, and call update_abstractmethods, and also accept possibility of it having subclasses, so they also call update_abstractmethods on its subclasses (perhaps even recursively).

An important consequence is, that decorators can only be reliably stacked on top of each other only if they are of the same category. And while update_abstractmethods can be used to adapt a category 1 decorator to category 2, there are no simple means to adapt to category 3.

Of course, the mere existence of a decorator of the third category is a case so far fetched that I doubt it even exists across all python code. This is a valid reason to discount it, but the implication is that if were to ever exist, it could not be used with virtually any other decorator.