> Parsing commands should be the responsibility of the shell and all the program should do is check for the existence of flags and values.

I would love to see more consistency in command line parsing, and I think argument splitting has helped add consistency for Unix-likes compared to Windows, but going further has some major challenges:

getopt(3) parsing currently depends on the accepted options. For example, the parsing of `command --option value` depends on whether --option requires an argument. Similarly for `command -cmyfile` which depends on whether -c requires an argument (or -m if -c doesn't, etc.).

For argument, lets say the shell implements the One True CLI Option Syntax™ and passes the parse result to programs. What are the big advantages over the status quo? A stronger encouragement for consistency than getopt(3)? Slightly less work for new option parsing libraries? Unfortunately, most of the code for option handling, which parses and/or validates options and option arguments, prints errors, prints --help, etc. would likely remain largely unchanged.

However, in the same vein, one area that I would love to see more standardization (although probably not at the OS level) is a more expressive way to declare supported options and arguments. There is all sorts of information beyond `struct getopt_long *` which would be useful for parsing/validation, documentation (--help and man pages), and shell autocompletion that is currently ad-hoc.