I already covered that in my question.
Current ACME protocol uses a “hardcoded” list of acceptable challenge types. Since its the server deciding if a authorization is accepted, it could process HTTPS/TLS challenges for wildcard certificates, but reject them as invalid (authorization failed) at the last step instead of issuing the certificate, on the server, even if the authorizations are in fact valid (since HTTPS/TLS isn’t acceptable for wildcard).
Basically, pretend to accept a HTTPS/TLS validation by providing the requied challenge, and then fail it at submission of challenge completion regardless of the actual authorization result. It does not even need to check if the HTTPS/TLS authorization is present, it could just immidiately fail it.
And only accept DNS-01 authorization of the base domain for wildcard certificates.
This means only the server software (inside Let’s encrypt server Machines) does need to be changed. The client software or ACME protocol does not need to be changed.