Sorry, but I don't know if its possible to make my argument any clearer than I've already made it.

If people are considering using GO::L because GO::Std doesn't allow enough options, they should seriously consider using an entirely different mechanism than command lines options to as the interface to their program. If 62 is not enough, it is far too complex to be driven this way.

If it is really necessary for a program with more than 62 configuration options to be command line drivable--as opposed to using (say) a configuration file--then the simple expedient of moving to two character options gives the possibility of nearly 1300 configuration parameters that are still 'packable', just as easy to look up, and if done well, far more memorable.

If people are considering using GO::L because they feel single character arguments are not memorable enough, they should re-consider, because most program usages fall into one of two categories.

1. Regular, often-used: as with tar -xvf ...

   In this case, the user will remember and use the composite argument far more easily than the long option equivalent.

2. One-off uses requiring the user to look up the required arguments.

   In this case, they will have to consult the man page or usage message to decide which options they need to use.

   Once they've done that, the selection of required options will be on the basis of the descriptons, not the option names. And it is far easier to remember or record and then type, single letter option names, than verbose long option names.

   People never remember all the possible long options for any given program, never mind all the long options for all the programs they use. And as is clearly demonstrated by the --no-mudflaps gcc option, and it's several related options; and many, many others, there is little milage in the 'self-documentation' argument either. Even with the full alphabet, and the possibility of multiple words, the originators of that particular optimisation still felt the need to use an obscure and particularly dubious analogy word as the name for the option. No one would ever guess what that option does from reading the long name.

   And that's far from an isolated example. Can you guess what these options do?

   • -mprioritize-restricted-insns=priority
   • -msched-costly-dep=dependence_type

My most frequently used no-short-option, long option, is wget's throttling option. I occasionally use this to allow me to continue surfing with reasonable responsiveness, whilst a long download runs goes on in the background, but sufficiently rarely that I have to look the damn thing up every time I do use it.

Is it --throttle-rate or --limit-rate or --rate or --limit or --rate-limit.

And I am always half way through typing the command before I consider using the option, and then have to abandon what I've typed so far, or start another session, in order to consult the usage.

I really wish that the authors had grabbed a trick from the tail and head tools arsenal and allowed -nn[km] as a short form for that option.

Summary: Long options are rarely a good idea and never necessary. And advocating GO::L "just in case", is a mistake because it encourages the perpetuation of a what was always a bad idea.

Any program for which you feel that more than half a dozen stackable, single character options are likely to become necessary, you should really consider whether there isn't a better way of making those selections.