Hugo's modular configuration syntax and strict validation are still in conflict

[FeRDNYC]

I’m posting this because just yesterday, attempting to upgrade an existing Hugo project from 0.147.0 to 0.162.0, I ran head-first into the exact issue described by @kaushalmodi in `hugo mod init ..` fails to create go.mod if hugo detects an error prematurely in site config.toml : Because the project uses docsy as its theme, and because the hugo.toml file contains:

[outputs]
section = ["HTML", "print"]

…I found myself repeatedly having to comment out that section of the configuration to avoid being stymied at every turn with:

$ hugo config
ERROR failed to create config from modules config: unknown output format "print" for kind "section"

$ hugo mod get
ERROR failed to create config from modules config: unknown output format "print" for kind "section"

$ hugo mod npm pack
ERROR failed to create config from modules config: unknown output format "print" for kind "section"

Now, part of this (I discovered later) was that the project also had a bad module path in the configuration for the docsy theme — "github.com/google/docsy" instead of "github.com/google/docsy/theme". But the fact is, that wasn’t what was causing all of the commands to fail, it was the "print" entry in [output] … even though the commands that were failing have NOTHING to do with Hugo generating output. While "print" was there, Hugo became effectively nonfunctional, including the Hugo commands that might have helped me address the missing module issue.

At the end of the discussion linked above, several months later, @deining asked:

@deining

From the inital post:

It took me some unreasonable amount to time to figure out what the problem was. I hope this is categorized as a bug and fixed.

I realize that this problem persists and is not only affecting me, but other hugo users as well, i.e. when using themes that bring in custom output formats. Therefore, as a friendly reminder and ping:

• Is there consensus that this can be considered as bug?
• Is/can this issue be tracked on hugo’s github repo?
• Any plans to address this issue eventually?

Thanks!

That was almost four years ago. So I guess, because this continues to be an issue, I’d also now like to ask:

• Does the Hugo team acknowledge the ongoing, user-impacting problem caused by the way Hugo validates its (pluggable) configuration?
• Is it acknowledged that hard-aborting when configs fail to validate because they contain options that would be supplied by a plugin that is not currently present (even for actions unrelated to the part of the configuration which failed to validate) makes working with the configuration, and therefore working with Hugo, significantly more confusing and productivity-sapping than it should be?
• Is there any possibility of this particularly sharp edge being rounded off, or at least dulled a bit?

I considered filing this as an issue, originally, but decided to start (or, continue) the conversation here, first. It can always go to GitHub as a next step.