Also, nothing prevents you from checking the host server-side according to arbitrary logic and putting it into the CORS header dynamically.

Nothing prevents this, but the client must still emit preflight checks (an extra round-trip) for every endpoint, and again if headers need to change.

Yah you saw that before I edited it out, I realized that gripe was actually about the behavior of AWS API Gateway rather than CORS itself. It hates the wildcard, or something, I can't even remember exactly what the issue was. Thus did I zap it.

I think what he meant is that the wildcard is not supported in the origin itself, for instance: https://*.somedomain.com.

per documentation, it's either "*" or "https://subdomain.somedomain.com"

That was in fact it, lack of a subdomain wildcard. I got really confused because I opened one project I thought had this issue, saw the ACAO header was set to *, and thought I hallucinated the whole thing out of some different issue. But it was a different project where I needed to allow internal access, which would have been easy with a hardwired response with a wildcard, but instead I needed to write a whole lambda endpoint just to pull out the requesting host and put it in the ACAO header. Also easy, but what a waste.

Either way, kind of a digression into details of CORS that wasn't necessary for the introductory treatment, so I edited it out.