Looking at the issue ( and the links you provide, thanks) it would seem that the issue is related to ACMESharp / windows - and the authors are looking to resolve that issue.
From my tests, I don’t believe this is the case at all. Like I said, if I take the exact certs that are generated by ACMESharp, and put them on a different Windows server, they work just fine. This purely seems to be an issue with the existing server caching the old intermediate.
On the server cert store itself (locally), it happily displays X3 as the intermediate in the cert chain.
At this point I’m 99% certain the issue is with some sort of cert caching mechanism in Server 2012 R2 and/or IIS 8.5. Not to say that the issue can’t be fixed elsewhere (for example, having a new intermediate issued, with completely different key). Just not sure LE will do that to fix an issue that is seemingly happening with only one particular type of server setup.
As far as my domain, it is behind CloudFlare and so can’t be tested publicly (it will return the CloudFlare certs, not the LE ones). Access to origin server requires client auth certs, which I’d rather not give out . The only reason I’m trying to get this working again is so that CloudFlare’s SSL strict mode will accept the certificates as valid again (since right now they show as invalid due to X1 being in the chain presented).