These answers are somewhat-theory for now since you can't actually disable providers yet, but:

What's the behavior when the last MFA provider I have configured on my account gets disabled and security.require-multi-factor-auth is enabled?

I think this case is okay: you'll prompted to add a new MFA factor when you next log in. As long as the install lets you add something, you should be alright. Example is maybe: install switches from TOTP to Duo, sends you 93 emails to switch, you don't. You come in on Monday and are forced to set up Duo. Seems okay.

A related question is "What happens when security.require-multi-factor-auth is enabled but no MFA providers exist / are enabled?". I believe the current answer is "you get a somewhat-clear-but-sort-of-dead-endy error that no providers are enabled, and can't continue logging in". I think users probably dug this hole for themselves so I don't think we need to bend over backwards to help them out of it, but it could probably be smoother.

We could possibly add a guard rail to prevent you from enabling the "require MFA" option if no providers are enabled (but I believe we have no other similar guard rails now, and we can't prevent users from editing .json files), or we could prevent you from disabling the last provider if the "Require MFA" option is enabled, but I'm inclined to wait until someone shoots themselves in the foot before actually putting these behaviors in place. I do think special-casing the error when it arises because of MFA-required-at-login is pretty reasonable, since we can easily give users more clear instructions ("You totally locked yourself out and should feel bad. Disable MFA requirements from the CLI like this, then add a provider so it's possible to add MFA, then you can turn MFA requirements back on again.").

(I don't think we should behave like MFA isn't required since this means the system fails wide open if there's some kind of bug in the MFA provider stuff -- better to lock everyone out if the config is nonsense than let everyone in.)

Actually, another question here that's just occurring to me is "What happens when MFA is required and only an SMS provider is enabled?". This is a question because you currently need to access Settings to add a contact number before you can add SMS! So that will need at least a little bit of adjustment, I think.

I'll make sure to run through the "MFA triggered by MFA-required config" stuff in more detail once these scenarios are actually testable.

Another possible thing is that sessions are long-lived and you only get force-MFA-gated at login, so an administrator might reconfigure MFA, think all the users are on the new stuff, and then learn that they a bunch weren't actually forced to switch to Duo or whatever yet since they're still on old sessions.

The current remedy is to kill every session with bin/auth revoke.

I'm inclined to say that maybe documentation is good enough here, especially if Auth ends up getting some better "who has this provider configured?" tools so you can obviously see that only 9 users have actually set up Duo or whatever.

But we could also think about other approaches. One thing we can do is downgrade sessions to partial without actually revoking them: so you don't have to type your password again, but you do get MFA gated if MFA requirements have changed. No tool currently supports this.