It really shouldn't _need_ to break anything, though mistakes can always be
made in some initial pass.
I would think you might also like long option key normalization so that one
doesn't have to remember when typing commands `--how-toSpell_OptKeys-exactly`.
Entering commands is often more ad
> To me this kind of optional symbol table seems both backward compatible and
> forward looking and strikes a good balance for a stdlib.
I have to admit, this is quite convincing. Especially since it's just an
addition to parseopt, breaking nothing, I hope.
cligen looks very cool, I'll need to look into it.
I'm also curious how other people feel about the args situation. In my personal
projects I've been using parseopt and having a user type ":" like the Nim
Compiler...
So, there have been various on again/off again conversations on github about
how the stdlib parseopt could/should behave. Those conversations seemed to have
a pretty narrow audience..basically participants on these github issue threads:
[4620](https://github.com/nim-lang/Nim/issues/4620)
