Unless I'm misunderstanding you: it's not about dev or prod. It's that you want Vercel to cache a dynamic page, but not your visitor. That allows you to be in control of the ship: if you purge the CDN, you don't risk a customer having a stale page.
I've seen a lot of customers get burn by sending `max-age` as a way of getting their CDN to cache, not realizing they're inadvertently caching on users' machines. Sometimes it's a seemingly harmless "5 minutes", but that can be damaging enough for rapidly changing pages (imagine breaking news on a homepage).
Look, regarding setting cache-control headers, it's a professional tool, and it's going to be possible to shoot yourself in the foot with it. The approach to try to reduce that is to have a UI that asks people, "hey are you sure you want to do this potentially dangerous thing? It just result in these unintended consequences", but yes, ultimately allow people to do it. Otherwise, you're not letting people use what they paid for.
Totally, I don't like surprising behaviors either. At the time we made that decision the `CDN-Cache-Control` proposal didn't exist, so it was a tricky spot.
There also really wasn't a UI opportunity in this case (although one thing we thought about was a setting to control it and turn off the Vercel override).
> There also really wasn't a UI opportunity in this case
Why, because the configuration is set in a text file and not in the UI?
You could send an automatic email to the account holder with the warning whenever someone adds a foot-gun cache-control setting, with the ability to turn off the email by setting a different configuration flag to true or by checking a flag in the UI.
