Alright, that’s fine.
Just be aware that we recommend against managing multi-SAN certificates: https://docs.https.dev/acme-ops#use-one-name-per-certificate
Case study: Caddy was the only ACME client unaffected by Let’s Encrypt’s recent CAA rechecking bug, which led to the mass-revocation event, because Caddy doesn’t use multi-SAN certificates. (It also does revocation checking and OCSP stapling, so even if it was affected, Caddy sites wouldn’t have gone down. It was also the only client at the time known to have this feature.)
As far as using multi-SAN certs to avoid rate limits, all that really does is lengthen the runway, but it doesn’t solve the actual problem. Caddy is designed to scale to millions of certificates; your client (or any client that uses multi-SANs as a way to circumvent CA limitations) is not.
Cloudflare also switched to single-SAN certificates. And they probably manage tens of millions of domain names.
Just saying, these are solved problems already at much larger scales than what any shared web host is operating at. Something to keep in mind.
Why predict? Just have them configure it. You can’t just switch from HTTP or TLS-ALPN challenges to DNS challenge anyway. You’ll need them to configure it if they’re controlling the domain.
If Caddy has already loaded a certificate with a subject that matches a candidate domain name, it will use that instead of obtaining a new one. (Unless of course you tell it to obtain a new one anyway.)
You really should go to the Let’s Encrypt forums about this though. They’ve had this conversation dozens upon dozens of times.