We should indeed add this note to the spec.
Some mechanisms that could be used to notify applications about this type of problem:

• Platform sinks can use existing error-reporting mechanisms (e.g., error event for media elements and maybe peer connectionss)
• We can define a signal that can be exposed via MediaStreamTrackProcessor.readableControl

This issue is still ripe. A note should be a sooner rather than later. An author of the WebCodecs specification author filed a Chromium bug due to the expectation that a MediaStreamTrackGenerator in a MediaStream set as srcObject of an <audio> element could be written to in a synchronous for loop without delay between calls and the audio would be output at the element at the same pace as delaying writes between calls to write() https://bugs.chromium.org/p/chromium/issues/detail?id=1260519.

the input to the MSTG is a Stream. I would suggest that the note should say that the client of MSTG (or now: VideoTrackGenerator) needs to respect the high water mark of the stream, otherwise frames may be lost, and that one should expect the MSTG to process frames at a rate no slower than real time, but not much faster either.