RFC(philosophy): Limiting depth of commands and subcommands in CLIs

[moul]

The current CLIs has multiple levels of depth for commands and subcommands, which can be confusing for users IMO.

I propose limiting the depth of commands and subcommands.
For example, we could switch from gnoland genesis txs add sheets to gnoland genesis txs-add-sheets.
This would make the CLI more user-friendly, as the first -h command would display top-level commands and subcommands ecosystems, and the -h of a subsystem would provide the full list of potential options, ideally sorted alphabetically.

[grepsuzette]

For example, we could switch from gnoland genesis txs add sheets to gnoland genesis txs-add-sheets

Only when it makes sense, but I would disagree this should constitute a philosophy.

To make up an example, if we had mycommand scripts maintenance certificates check_validity, it would be deep, but if the depth was proportionate to the rarity with which it was typed, or if the depth allowed the local tree of subcommands to be well-balanced, it would not only be fine but arguably better to a shorter command such as mycommand scripts certificates-check-validity.

Of course there are a lot of cases where limiting depth is not only acceptable but superior.