NASCAR in the wild! Best practice has mostly replaced this sign-in experience with an identifier-first discovery flow, which means the site can figure out which IDP the user chose the first time instead expecting the user to magically remember

Not as easy as it looks :) Identifier 1st works beautifully for work & school, but the same personal email address could be associated w ANY of the providers shown there, including more than one at once. Openid pre-connect tried to solve by imposing unique IDs, didn't pan out

Interesting! Question: another thing I struggle with here is that it seems that an RP needs to register out of band with an IDP before they can accept users from that IDP. Contrary to email, where any email provider goes in a username/password form. Is that also solved?

It honestly very much depends on how the RP builds their backend. Generally speaking, RPs that let you disconnect or connect a federated provider on the fly, have a well structured IAM backend / database.

Doesn't this depend on the IDP to hand you a client_id before hand?

Yes, that would always be the case for these types of use cases.

So, even if a RP wanted to accept an IDP dynamically (e.g. without a prior agreement, i.e. without a client_id) it wouldn't be able to, right?

There are discovery mechanisms but they're not widely used for this use case.

Is there any existing mechanism (even if not widely deployed) that would allow a user to use an IDP with an RP dynamically (i.e. without a pre arrangement between the RP and the IDP)?