E1, E2, R3, R4 - new naming scheme with non-overlapping numbers
despite R3 being deployed before E1:
they are in the same numbering system
3/4 are signed by ISRGROOT-X1, 1/2 are signed by ISRGROOT-X2
Also, in addition to the above... a properly operating client shouldn't have any issues with switchovers from X3/X4 to R3/R4. (A new Fake-R3 would have been nice on the staging server though!). When E1 starts issuing in parallel, then clients will need to adapt (related thread Questions re: Beginning Issuance from R3)
Not really I guess. Now, when you request issuance for an ECDSA cert, it'll be signed by R3, as E1 isn't in play yet. Nothing to choose. However, when E1 does get enabled and you'll request issuance for an ECDSA cert, it'll be signed by E1 and no option to get it signed by R3: it'll depend on the public key in the CSR which private key will be used to sign the leaf cert, R3 for RSA, E1 for ECDSA. No adaptation required by the client.
Yep, this is all correct. And @Osiris is right: clients shouldn't need to adapt when we start issuing from E1, assuming they are using ACME correctly. The certificate response include the full chain to use.
My client doesn't natively support ECDSA certificates natively right now, and there is no plan to do so in the near future. If I have time, I'll test some CSRs with it and write something to generate them. It's good to know I shouldn't have to do much to support them though!
When E1 goes live, I will have to write a bunch of test cases to ensure we're getting signed by the right root lineage.