My plan here is:

• Active: users can add new factors.
• Deprecated: users can continue using their existing factors, but can not add new ones (example: you want to move from TOTP to Duo, so you deprecate TOTP).
• Disabled: users can not add or use factors.

I think it's conceptually okay to have multiple factors for the same provider.

For example, maybe two different subgroups at your org set up Duo independently, and then you adopt Phabricator, and then everyone realizes no one was talking to each other. So you configure both Duo accounts and call one "Ops Duo (Use This One)" and one "Eng Duo (Deprecated, Do Not Use)" and then move toward merging them, but everything works as-is for now and you don't need to transition half the org on day one.

(Or you have a 128-bit TOTP source and a 256-bit TOTP source and move from one to the other, perhaps.)

Most of the uses I can come up with are around gracefully transitioning between providers, but this kind of "one old version, one new version" smooth transition seems pretty reasonable.

Yeah, you probably shouldn't have two providers with the same name.

However, if we enforce UNIQUE on the column, you can't use the default/empty name for two providers at the same time. The field is optional and providers get sensible (and i18n-able) names if you leave it blank, and it seems reasonable to have a default-named SMS provider and a default-named TOTP provider at the same time.

I guess we could put a unique key on both columns (<providerFactorKey, name>), but maybe having a default-named, disabled provider and a different, default-named, active provider of the same type is okay?

This mostly just seems like it's probably not something we really need to enforce technically unless this UI proves way more confusing than I expect it to be, even though cases where two providers have the same name are probably not ideal.

Yeah, we ended up with a fair number of copies of this. I'll throw it in a method.