Currently, for requests for Pardoid content with a specific TID, it the content cannot be served from storage, RESTBase creates a new render and responds with 200. It might be wrong. If a specific TID was requested and can not be satisfied, RESTBase should probably 404.
However, it's up for discussion. For VE serving matching-tid is crucial - doing the data-parsoid by-tid requests on the best effort principle could be catastrophic and it can create a dirty diff without the user realizing what's happening. But here, again, we are facing a product decision - what's better - reject saving an edit that the user might have been working on for a while, or force-saving it regardless of the possibility to create a dirty diff. Maybe someone from #visualeditor could provide some thoughts on that?
For reading content, like MCS and PCS, non-matching pieces of content (tids) might not be such a big deal and rejecting the user from reading the content that might be a bit stale seems worse.
Please note, that events of TIDs not being found should, in theory, be impossible and should be results of a bug in the software, so the decision we're making whether to make TID requests strict or best effort is more theoretical than practical