I'd like to see handling for this header limited by client ID. If an API developer or SRE is using their development client ID to test the API gateway, great.

1. That will make it useless for unauthenticated (no client id) access.
2. The primary use-case for this is for config deployers to verify that the change they are deploying didn't completely break down the site. Config changes are sometimes deployed by other teams or volunteers, the process is very well established. Making one-off exception in the deployment process does not seem worth it.

But a public client won't get used to using the cache-busting feature in their production app and then find out that it's no longer allowed.

Bypassing the caches is implemented in Varnish/ATS and we have no control over it. Verifying client-id on the cache level is not possibly, thus the cache bypassing is here to stay no matter what.

Although the feature is obviously useful for testing the internal network, there are parts of it (cache-busting, read-only) that could become undocumented features.

If that is a concern (IMHO, it's not a concern) we can rate-limit access with a debug header to some really low values.

TLDR: I vote for declining this task.