If you're only interested in "option files, option file groups, individual options, and command-line arguments", you can use my_print_defaults --mysqld — which will show you exactly what the server will see and in what order.

Verbose messages as you suggest will be only marginally better than that. And both won't help with the cases of "build options, environment variables". I can see that technically one can have verbose messages for environment variables too. But what to do with build options?

I'd probably rather have a list mode, similar to what we have in --help output, that shows for each variable by which way the most current value was set: compiled_default, env_variable, cnf_filename (which can be different names when the !include feature or --extra-defaults-file is used) ...

The "default" options (set at build time) can be inspected by using

--no-defaults --help

.

A problem with my_print_defaults is that the list of option groups read by the program will need to be copied from the program. That is difficult to do programmatically and is difficult for a Support Engineer to communicate to a customer (since the list of option groups will be different depending on the product, the tool, the version, etc.). Furthermore, my_print_defaults is distributed (in the case of RPMs at least) in the MariaDB-server RPM, meaning that it will not be available for client-only installations.

I think some verbose mode even for my_print_defaults would be useful. Knowing the value of a variable used after option processing is not the same thing as knowing how an option was set or how the variable was overwritten multiple times. In many cases, multiple files contain the same options and it can be difficult to track down which things are coming from which files, which files are being read, in what order files will be read, etc.

I'd like to see output showing the names of option files as they're read, the names of option groups as they're processed, the names (and values) of variables as they're read, command-line options as they're processed, environment variables read, etc.

The goal for me would be to trace the lifecycle of variable values during server startup so it was possible to fill in the gaps between

mysqld --help --verbose

and SHOW VARIABLES.