But, however in that regard it is interesting to see the shoe on the other foot for Firefox this time around.
Historically Firefox used to rely on remembering recent intermediates it had seen to "fill in the blanks" when trying to access a site that doesn't bother providing any reason to trust the certificate it offers†.
But, Mozilla spent years collecting knowledge of all unconstrained intermediates for trusted root CAs. Then they shipped the entire set as part of Firefox. So, a modern Firefox visiting a site that only has a Let's Encrypt certificate and no other reason to be trusted, sees that and goes oh, that's issued by Let's Encrypt's R3, which I have a copy of, and so it's trustworthy. Done.
Whereas for several other popular browsers they're looking at potentially stale local information, and may conclude that they can't trust this site because some stale data has expired or they rely on an already expired certificate sent to them in some cases rather than disregarding it.
† You're supposed to provide a "chain" (it doesn't actually need to be a chain, but that's most compatible) of other certificates to show why the leaf certificate you have is trustworthy, e.g. my certificate is from Z9, Z9 has a certificate from Big Trusted Corp Q46, Big Trusted Corp Q46 has a certificate from Very Famous Trusted CA, and the relying party (well, their client software) goes, "Oh, I see, and I trust Very Famous Trusted CA, so that means I trust you're you". But, lots of web sites (maybe 10-20% and more of the smallest with negligible IT budget) don't get this correct so web browsers try to work around it.
There's two Let's Encrypt issues at play at the moment.
The issue that your comment about cached/discovered intermediates relates to is that some servers were still manually constructing the chain that goes leaf -> R3 -> DST Root X3, and the R3 intermediate signed by X3 expired on 29 September. This chain hasn't been returned by Let's Encrypt since May 2021.
The other issue relates to the current default chain returned by Let's Encrypt that goes leaf -> R3 -> ISRG Root X1 -> DST Root X3 for Android compatibility. Most clients are able to successfully build a valid chain from the leaf to the still valid ISRG X1, however, old versions of OpenSSL (pre-1.1.0) and several other TLS libraries that don't explore the graph correctly barfs at a chain that terminates in the now expired X3 root.
Well, you're right that there are two issues, and it's perhaps unfortunate that ISRG chose to arrange that they happen next to each other (but to be fair I don't think we pressed them to do anything else back when it would have been possible, although I'm behind on some reading I don't think I'm that far behind)
But, in both cases Firefox's choice works out for it regardless. And unfortunately I believe -- though it's hard to tell for sure -- that some other browsers get the missing certificate case wrong, perhaps for a few hours and perhaps much longer. Lacking a guiding hand, they may end up choosing to "validate" the R3 -> DST Root CA X3 case which can't work. I think some logic will eventually expire this useless data and those browsers will work, but obviously that's not helpful if your site seems "broken" now.
It will be clearer by tomorrow, but understandably Let's Encrypt's community site is under a deluge of "Help!?" type posts, which are a struggle for the volunteers.
