Just looking at these two issues, it seems like many users are radically unprepared for changes in intermediate certificates:
(I think Let's Encrypt has been very clear on the issues and best practices around this, so I don't think Let's Encrypt did anything wrong here—it's not unreasonable to expect people relying on Let's Encrypt services to read the documentation and/or subscribe to API Announcements and/or talk to someone from Let's Encrypt about whether they did it right.)
In a few other cases, such as the v1 API deprecation, Let's Encrypt has used a "brownout" approach to try to make sure that a change will come to subscribers' attention before it fully takes effect.
I wonder if a similar approach would be useful for (scheduled, non-emergency) intermediate certificate changes. For example, maybe the API at the regular URL would start issuing from the new intermediate on a certain date, while there would be a temporary "legacy" API that still issued from the old intermediate for, perhaps, 90 or 100 days afterward. It could be called
thisservicewillgoawayonjune7.api.letsencrypt.org or something.
In that case, people who were surprised by incompatibilities involving the new chain would get one additional certificate lifetime in which to act to remedy things in response to that surprise.
(I realize this could represent a lot of extra back-end engineering work, depending on how many things in the production API assume that all CPS-relevant issuance is coming from it—I remember that there were two different intermediates which were designed to operate in parallel at the time of Let's Encrypt's original launch, and that turned out not to be a convenient design.)