The puppet configuration logic with its systems of defaults works fairly well. The scheme of "important" and "safe to change" options as explained on https://docs.puppetlabs.com/puppet/latest/reference/config_important_settings.html is a good way to approach the multitude of possible settings. In particular, settings such "server" and "vardir" have potential impacts for many other settings because these root settings propagate down as defaults for other settings.
It is important to preserve this propagation/inheritance and override the subsequent options only when they don't follow the default rule. Otherwise, a change at the top level will not be propagated as expected: in the best case, the admin will have to carefully and manually check all the other settings in puppet.conf to insure correct behavior. Note that the generated puppet.conf file is very long.
Unfortunately, the generated puppet.conf does not follow the above logic: it explicitly sets several options (10's) to the default value meaning that when someone changes a higher level setting (e.g. "vardir" or "server"), the defaults do not propagate.
One example: "vardir" is regularly used as a default starting point for many other directories (see the attached file "vardir.grep" to see how many times it appears in the generated puppet.conf file. However, changing it may, or may not, change the subsequent values (the generated puppet.conf file is inconsistent in this manner as well). Here, the "clientyamldir" setting would not be impacted (see attached "client_yaml.grep") as one might expect. The admin needs to search through and find every place where things should (normally) change. Explicit overrides should be just that: explicit and overrides.
Fix: --genconf output should not explicitly set values that have reasonable defaults. These potential settings should remain in the conf file as comments. E.g. the client_yaml "setting" should become:
" # The default value is '$vardir/client_yaml'. "
" # clientyamldir = /var/lib/puppet/client_yaml "