JSON API caching translation paths when using non-anonymous role [Drupal 10.2 regression?]

We have a decoupled site, with the front end built on Gatsby using the gatsby-source-drupal plugin. While the json endpoints may be public, the actual entity access is limited by role. We create an user with a custom "json api access" role, and use the Drupal key_auth plugin to get a key unique to that user. That key is provided in the headers of the requests that the Gatsby application makes to the Drupal site to retrieve and build its data.

The Drupal site has translations enabled, currently providing EN and ES. When hitting a particular resource listing for a language with a properly authenticated query (ex: https://my-site.tld/es/jsonapi/node/my-content-type) we get "paging links" at the bottom (ex: https://my-site.tld/es/jsonapi/node/my-content-type?page%5Boffset%5D=150&page%5Blimit%5D=50), which permit the Gatsby builder to walk through and get all the appropriate nodes, so it can then sift through by various criteria including langcode.

Or at least it used to, before we updated Drupal to 10.2.0, and started observing a problem that persists in 10.2.2.

Now, under the conditions I've described, a hit to the EN endpoint (which is really the default: https://my-site.tld/jsonapi/node/my-content-type) eliminates the langcode in the paging links of the ES endpoint. So for instance:

1. Hit to https://my-site.tld/es/jsonapi/node/my-content-type returns https://my-site.tld/es/jsonapi/node/my-content-type?page%5Boffset%5D=150&page%5Blimit%5D=50 in the paging links, as expected.
2. Then, hit to https://my-site.tld/jsonapi/node/my-content-type return https://my-site.tld/jsonapi/node/my-content-type?page%5Boffset%5D=150&page%5Blimit%5D=50 in the paging links, as expected.
3. Then, hit to https://my-site.tld/es/jsonapi/node/my-content-type again returns https://my-site.tld/jsonapi/node/my-content-type?page%5Boffset%5D=150&page%5Blimit%5D=50 in the paging links. The /es/ portion of the path is gone.

Clearing the site cache will correct the problem once, but not for subsequent requests.

Finally... and this is the really odd bit, it all appears to be bound up in authentication.

• If the API is hit by an authenticated account with the custom role using the api-key, the problem is observed.
• If the designated API user account is given the "administrator" role, it still happens.
• If the "anonymous" user is given "view published content" permission, and the API hit with no authentication (no key), the problem goes away.

My supposition is that cache tagging is folding together language and authentication parameters in some way, that's blocking consistent behavior. Our current workaround is a custom event subscriber that forces the cache max age to 0 on any jsonapi path.

Following on all this, I have two questions:

1. Why would this not have been a problem before, but is now?
2. Why is there not (or is there) a means to disable caching specifically on the jsonapi endpoints? It seems to me that those would be something we'd usually want to be evergreen.