On namespaces...
Like MIBs, APIs, file systems, most anything, it's usually... least specific left to most specific right ... DNS also maintains hier but in reverse direction.
add_foo_thing1 add_thing1 add_thing2 see_bar_thing1 string_assorted_junk_this ...
gives you hierarchies of *add* filled with all sorts of random things, doesn't sort, and leads to documentation being scattered as well, with assorted junk everywhere.
ONION_CLIENT_AUTH_ADD
is most clear... ONION (ok, what about onion), CLIENT (ok, what about client), AUTH (ok, and...) ADD (aha yes do that). And docs are self ordering into nice sections.
ONION_CLIENT_ADD_AUTH
doesn't follow because it reverses the last two thus breaking things again.
"We can't change"
Sometimes these positions can hold you back, allow random in new things, expend mantenance on old chaos, etc. If project codebases have a lot of legacy chaos, downstream can appreciate and support refactoring in major releases, even if they have to do a little work themselves to get that. Announced mapping of legacy command support for removal in next major releases can help there too.