If content makes a series of mapAsync requests without waiting for the resulting promises to be settled, since validation happens on the device timeline, the device will accept the first valid request, and reject all the others before and after it. Since the content timeline can't tell which of the promises is going to be accepted, it must retain all of them until it gets news from the device timeline. This seems unnecessary and unhelpful.

In a bit more detail:

Suppose content makes a series of mapAsync requests on a GPUBuffer in the "unmapped" state, without waiting for any of the promises to resolve, and without any intervening unmap requests. The language around mapAsync is under revision, but I believe even in the revised language, the first such mapAsync that passes validation puts the buffer in the "mapping pending" state, and all preceding and succeeding map requests get rejected.

I would like to suggest that the content timeline return immediately rejected promises for all mapAsync requests but the first, until that first request's promise is settled (either rejected or fulfilled). This would allow the GPUBuffer implementation to retain only a single promise, simplifying its state. This also seems to me to be a more predictable API: there is no possible use for a series of mapAsync calls without waiting on the promises.

This would remove the ability to fire off a series of mapAsync calls to see which one succeeds. That seems like a niche use case; the conditions under which mapAsync succeeds are pretty predictable.