Our current implementation of rate limiting requires serial access to uncached data. This may evolve in the future as the technology proves itself and we see more data on how it is accessed. If you receive a 429, then this means that you currently have another request that has not yet finished processing and caching the result. Even though you can access cached data as fast as you like, it is safest to request in serial rather than in parallel.
If you do receive a 429, then this approach to rate limiting does not permit us to let you know when you may try again — the rate is not time-based. So no "Retry-After" header should be expected.
We currently have a bug where if you make a request for uncached data, and that request fails for some reason, then you will be blocked on all future requests for other URLs until you (or someone) requests that URL again and it succeeds. This is a bug and we plan to address it soon. However, it exposes a problem: if you receive a 429 during parallel requests of many URLs, it is not always clear which URL failed and must be re-tried. If you have suggestions on how you would like this information communicated, I'll see if we can support that.
While I have not received a 429, I am being cautious and limiting my request rate in some small projects of mine. Out of curiosity as well as future reference -if I ever need to handle a 429-, though, is it safe to assume you will be providing a "Retry-after" header?
Edit:
Sorry, I meant that I have not received a 429. I have edited my question to clear that up.