This issue originates from: #99095

A description of the problem and possible solutions mentioned by @xinhaoz:

So the problem is that we always compare the request time of the current in flight req with the one managed by the CachedDataReducer, and since there's one CachcedDataReducer issuing all reqs in the Keyed one, we always rewrite the pending request time for each new request. So multiple reqs managed by one KeyedCacheReducer will all use the same pendingRequestStarted time in the promise resolver callbacks.

There's a couple of different things we could do as alternatives to the fix here:

1. In a similar way to address the issue as this PR is currently doing, just add the gate to when we set the pending request time. e.g. (if allowReplacementReqs, then do all the pendingReq setup before we dispatch the request data action / call the api).
2. An approach that would allow the KeyedCacheDataReducer to allow replacement reqs if we ever desire that (which I assume we might) -- it's a bit more involved, but we essentially just move the fields for comparison of whether or not the request being resolved in the promise is the most recently dispatched req to the state. There's already requestedAt in the state. We can probably use that in place of pendingReqStarted. This approach might be bit finnicky to get to a nice state because the requestedAt is currently set in the reducer, and we dispatch the REQUEST action in the refresh method meaning we can't wait to get the requestedAt synchronously... To circumvent that we can probably provide the requestedAt time when calling requestData().