Currently the set of CLI flags added to Wasmtime has been ad-hoc and generally "throw another option in there" style historically, which is great for easily adding new options (which happens a fair bit), but I personally feel like there have been some growing pains that may be worthwhile to address sooner rather than later.

Some concerns I have with the current CLI are:

• Discoverability is hard right now as --help or -h prints out quite a lot of information.
• Not a lot of single-letter flags are in use so CLI commands tend to be quite long
• It's tough to review "at a glance" what Wasmtime's capabilities are on the CLI through the help page since there's so much to sift through
• Some options have little papercuts like trying to remember --dir vs --mapdir, there's no way to inherit the caller's environment or a single env var from the environment easily, etc.
• Options can be randomly --disable-foo or --enable-foo and it's not clear why which is which when you're approaching the CLI for the first time.

To be clear none of these are dealbreakers by any means. While I think the Wasmtime CLI is important the embedding API are where things "get serious" so it's ok for the CLI to not be perfect. That being said folks often interact with Wasmtime through the CLI to start off with and it's also mega-useful during development and debugging and such.

So given all the above I'd like to propose a (hopefully) brief bikeshed about the Wasmtime CLI. I'd like to ideally address the above concerns and provide guidelines of how to add new options into the future. This will hopefully clean up our CLI, make it a bit more ergonomic to use, all while not hindering our ability to easily add various knobs here and there as they're implemented.

At a high level my proposal is "let's do what rustc does". I'm very biased in that regard as I helped design rustc's CLI as well. Some things I like about rustc though are:

• The output of rustc -h fits more-or-less on one terminal. This serves as a good index from which you can learn more.
• There are "option groups" that are behind other flags, such as rustc -C foo or rustc -Z foo. These single-letter capital flags are easy to type and easy to remember and serve as a good place to house sub-options.
• More information can be read through rustc -C help which provides an window into all the codegen capabilities of rustc
• Instead of --enable-foo or --disable-foo most rustc options are -C foo for --enable-foo or -C foo=no for --disable-foo. This makes it easy for callers to forcibly enable/disable something and you don't have to worry about what the defaults are since as a user you typically want to turn something on or off and you don't care too much about whatever the default happens to be.

My proposal here for Wasmtime's option groups are:

Codegen options (-C or --codegen)

• All --disable-foo flags become -C foo=no
• All --enable-foo flags become -C foo
• -C foo is shorthand for -C foo=yes
• *=yes can support y, yes, true, etc
• *=no can support n, no, false, etc
• Non-boolean flags support -C name=val where val is parsed as whatever
  name wants.
• Can support comma-separation as well such as -C foo,bar or -C foo=n,bar

Runtime options (-R or --runtime)

• Various *-unknown-* options are all -R unknown-* now.
• Same system for boolean flags as -C options

WASI options (-W or --wasi)

• Separate from runtime options as this'll have WASI-proposal-specific
  configuration options.
• Leave --env as its own standalone flag
• Add support for --env FOO which inherits the env var FOO from the outer
  process.

Other flags

These are the other flags supported by Wasmtime which don't necessarily fit into the groups above. They're either important enough I think they should stick around at the top level or they have enough of their own "sub-syntax" that I'm not sure they fit well in the groups above.

• --wasm-features <FEATURE,FEATURE,...> - perhaps add something like a -F
  shortcut, I find it a bit annoying to always type this out. Support --wasm-features help for the extended help section on this.
• --preload <NAME=MODULE_PATH> - allow omitting NAME and infer it by default
  from MODULE_PATH.
• --profile <STRATEGY> - leave as-is
• --invoke <FUNCTION> - leave as-is
• --allow-precompiled - leave as-is
• --target <TARGET> - leave as-is
• --output <OUTPUT> - leave as-is
• --emit-clif <PATH> - leave as-is

I'm curious what others think about this! If it's broadly amenable and folks are ok with the breakage I'm happy to implement this myself, I don't think it'll take all that long (perhaps just a day or so)