You're brave, posting an invitation like that on the Internet. 
Hmm, what came to my mind was "Ye Olde Shoppe" type spelling. And "YR" made me think of a pirate's "Yarr!", or maybe Lt. Yar.
I do like this sort of thing better, though 2-digit years still make me twitchy (At the rate the industry is moving, Let's Encrypt will still need to make RSA roots 100 years from now to support legacy clients, right?). But date-as-versioning seems to be catching on in a number of places, and may have some advantages.
Is there a shortage of numbers I'm unaware of? It sounds like you're trying to stay within 3 characters, sure, but just incrementing a number seems simple enough, at least until you get to 100.
Last time we were nitpicking the names, I kind of liked giving them actual "names" if we were going to need a name at all. Even within three characters, there are plenty of names one could use that would be memorable. Ivy, Ava, Leo, Eli, Ian. Kai, Max, Ann, Dee, Joy, Sue, and that's just with a quick search. And I still think allowing donators to get premium "shiny" pokemon or other pop culture names for their intermediates isn't the worst fundraising plan out there. (Or maybe to get shorter single-character intermediate names? An emoji-named intermediate like CN=🔐?)
Moving away from the silliness of choosing names by committee here, and onto some actual technical questions:
I would like to hear the reasoning for continuing to use P-384 for intermediates instead of P-256. Especially if the security of 2048-bit RSA is acceptable for the length of time the intermediates are expected to be in use, and P-256 is generally much more performant and studied. See @Nummer378's commentary from the prior round of intermediates. We also had a thread here a couple months ago where a user had to switch to RSA because the system they were communicating with couldn't handle P-384 signatures but maybe could have handled P-256 better.
And if the answer is that the added cost of P-384 is just worth it for a longer-lived key like an intermediate, why wouldn't that same logic apply to the RSA side and mean a longer key than 2048 ought to be used there as well?
So, you used to have two of each (one for main use for the expected lifetime, and one for a "backup" which has never been used. The last time around, you made five of each, primarily using two in a "random" fashion and leaving three initially unused. There was some talk of intentionally switching to some of those unused ones after a year or two, but that doesn't look to have happened. What's the reasoning and plan behind having three this time around? I don't know as I particularly object regardless of the number there ends up being, just being nosy and curious about a change. Would it still be two in active use initially, with the third as a backup?
I'd love to know an estimate for how much bandwidth this change will save the Internet per year.
This surprises me (and as @bruncsak mentions, seems counterproductive to the goal of minimizing handshake sizes). What user-agents are you thinking of that would remove ISRG Root X1 and/or X2 while adding these new roots? I'm not aware of any that removed X1 when you added X2. There's nothing special that Let's Encrypt is doing here compared to other CAs, right? Do other CAs plan on only having one generation of roots in trust stores at a time and expect their sites to always send cross-signs from the prior generation?
Thanks!