Since a "federated OAuth flavor with user IDs that can switch authority" (as is the case of did:plc), is inherently incompatible with OIDC (in which a client has to know, and trust, the authorities in advance), we didn't want to tie our specification with OIDC to avoid misleading devs.

I would ask you to not give up on OIDC too easily. See for example the way Tailscale implements custom OIDC providers. You give them an email address, and they use WebFinger to look up the OIDC provider. I've found this to be an excellent way of doing things.