To resolve the common case of an autocreated Unactivated A, we could have getOrCreateOpenIDIdentifier rename B account away, rename A into its place, transfer the OpenID identifier across, request a B -> A merge, then activate and log into A.
Other cases are probably rare enough that they can be handled manually; we should reject the login like we do in the team email address case. If A is active then the user can work around it by using their other SSO account, and a manual B -> A merge will unbreak things.
If A is deactivated, we probably don't want to reactivate it; we might want to have a way for an admin to erase the email addresses and OpenID identifiers from a deactivated account to give a user a fresh start, or just use the classic merge to lp-void approach.
To resolve the common case of an autocreated Unactivated A, we could have getOrCreateOpen IDIdentifier rename B account away, rename A into its place, transfer the OpenID identifier across, request a B -> A merge, then activate and log into A.
Other cases are probably rare enough that they can be handled manually; we should reject the login like we do in the team email address case. If A is active then the user can work around it by using their other SSO account, and a manual B -> A merge will unbreak things.
If A is deactivated, we probably don't want to reactivate it; we might want to have a way for an admin to erase the email addresses and OpenID identifiers from a deactivated account to give a user a fresh start, or just use the classic merge to lp-void approach.