The one part that stuck out to me as surprising was your proposal to represent this in the configuration.

yes, it is entirely possible that in some cases there might be break-the-glass procedure that handles case where CI/CD is down and is allowing deploys using elevated credentials, being able to specidy "problem" in confiugration itself will be portable outside CI/CD and can be flagged by tools like TFLint as warning - you have part of system disabled. So you get consistent behaviour no matter where you try to execute opentofu with given state and configuration.

I've typically wanted "incident-related" controls to be something I can do outside of the configuration

I do feel that we would need to support both, in-configuration and via environment configurations to cover majority of users. It might be easiest to add variable in CI/CD but if it is multihour outage you might want to propagate knowledge outside CI/CD without relying on human memory.

I remember us noting that someone responding to an incident might choose to temporarily reconfigure their execution system to set the environment variable TF_CLI_ARGS_plan=-exclude=provider.sass_vendor as the way to impose that setting only for the duration of the outage. I assume you'd consider that as equivalent to -target and so not an acceptable answer for similar reasons?

I would consider any working option that allows to mutate resources controlled by working providers during outage, yet today https://opentofu.org/docs/cli/state/resource-addressing/#resource-addresses-on-the-command-line does not mention ability to filter by provider. Typicaly, --exclude and --target work on resource address, and unfortunately they are not prefixed with provider name, only with parent modules, so require rather big knowledge on namings. If this filter would work on provider name it would do the trick (but it would be rather confusing that resource targeting flags accept not only resource addresses).

Worth noting that historically, terraform, did refuse to do targeted run when some dependency for graph is not included, and required to target all missing dependencies as well if they are needed to build graph of changes. Potentially solution could account for muscle memory from aincent times a bit as well. Current proposal implies different behaviour and different flags to not confuse the two: in proposed scenario we know that there is no way to use given provider, and switch to mock it out using knowledge in statefile instead of considering it being part of graph.

Thanks for the extra details!

And indeed I do want to be clear that the option to exclude by provider in the -exclude option is only something we considered as a future extension, not something we already implemented. My intention for mentioning it was only to test whether that earlier idea might be a reasonable way to solve the problem you presented, which you've answered clearly already. Thanks!

Thank you as well for clarification.
Can we please link previous discussion(s) here, so people who find this one can follow on to the "correct" one?

This was part of the design discussion that led to Exclude Flag for Planning and Applying being written and accepted, but it doesn't seem like that part of the discussion was recorded in the final RFC since the RFC focuses only on what was actually implemented and doesn't discuss the ideas that were eventually considered to be out of scope for the first project.