This is a request for comment. I often stumble on trying Set Debug Typeclasses or Set Debug Ltac while the official syntaxes are "Set Typeclasses Debug" and "Set Ltac Debug". That Debug comes second for Typeclasses is legitimate from the point of view of Typeclasses since we already have:

Set Typeclasses Unique Solutions.
Set Typeclasses Modulo Eta.
Set Typeclasses Dependency Order.
Set Typeclasses Iterative Deepening.
Set Typeclasses Depth.
Set Typeclasses Strict Resolution.
Set Typeclasses Unique Instances.

However, this contradicts the point of view of Debug options where Debug comes first as in:

Set Debug Unification.
Set Debug Tactic Unification.
Set Debug RAKAM.

So my questions are somehow: should we obey to the principle that we should avoid providing redundant syntaxes, or should we consider that convenience is an as important requirement. Alternatively, should we arbitrate between the Typeclasses point of view and the Debug point of view and have only syntax, or should we accept that both points of view are valid and have the two syntaxes coexisting.

Regarding Set Ltac Debug, the situation is different. Historically, we had Ltac Debug. By care for uniformity, I introduced Set Ltac Debug which is now the official, documented, syntax even if Ltac Debug is still supported by an ad hoc entry of the parser. Following the Debug view, we could also accept Set Debug Ltac. But then we should morally document both since, one makes sense from a Debug-centric POV, while the second makes sense from an Ltac-centric POV.