If you really want to include the word "only" in your sentences (you really want to do that, it seems), you should also say that for the current situation, ACME clients will, by default , serve a certificate chain that only leads to DST Root CA X3.
Otherwise the word "only" still doesn't make sense.
My guess is that (one of the things) they're working on before bringing the new intermediates into service is updating the CPS. Section 7.1 only mentions the X<n> certificates, so I'm guessing they need to add at least the R<n> certificates there before they can be used. So keep your eyes peeled there if you want another hint of when they're about to use the new intermediates.
(And there are even more changes they need to make before using the E<n> intermediates. Actually, it seems weird to me that 1.1 has been updated to say it includes Root X2, while the rest of the document, like section 6.1.5, still says that roots are RSA keys. It's things like that which make me think that updating all the "paperwork" is what's holding up the use of the new intermediates, though I'm just a "layman" and I'm sure I don't know all the steps involved.)
Hi everyone! For all of you guessing that issuance would begin from R3 "soon", you're right! See the announcement post here: Beginning Issuance from R3
To answer the original question: No, you will not be able to configure whether your end-entity certificate is issued by R3 or issued by X3. When we begin issuance from R3, it will be replacing X3, not co-existing side-by-side.
Some additional context and detail, to help remove any pieces of confusion brought up in this thread:
As @_azpointed out, there are two separate events coming up: changing our issuance from X3 to R3, all while continuing to chain up to IdenTrust's DST Root CA X3 trust anchor; and then changing our chain from DST Root X3 to our own ISRG Root X1 trust anchor. The former is time-constrained by the expiration of our X3 intermediate (it was issued with 5 years of validity back in 2016); the latter is effectively time-constrained by the expiration of DST Root CA X3 (it was issued with 21 years of validity back in 2000). Although these events seem related and are happening at around the same time, conceptually they are wholly orthogonal and could happen in either order, completely independently.
When we talk about chains of trust, it is really easy to get confused about what it means to be "issued by" something. Remember that certificates do not issue other certificates: private keys issue certificates. The acme client does not have control* over what private key is used to issue the requested end-entity certificate. But, there might be multiple certificates which all say "I trust this intermediate public key", signed by various different root private keys. In our case, all of our issuing private keys (e.g. X3 and R3) have two certificates indicating trust in them: one each signed by IdenTrust's DST Root CA X3 and by ISRG's Root X1. Our ACME API provides as a courtesy the ability to control which of those two certificates you get bundled with your new end-entity certificate. But at the end of the day, they both represent the same private key which issued your new cert.
* It will have some control when we begin parallel issuance from E1: the ability to choose between R3 (RSA) and E1 (ECDSA). But that's a separate conversation.