From a discussion with @jdarpinian.

To reduce the fragility of the API, lost devices should appear to function as usual, as much as possible. In particular, we should avoid causing exceptions or promise rejections due to lost devices, as this could cause unexpected interruptions in arbitrary places in user code, potentially preventing them from recovering correctly.

• mapAsync Specify behavior of onSubmittedWorkDone/mapAsync on device loss #3937
• onSubmittedWorkDone #^
• popErrorScope Stop raising errors during/after device loss #4051
• uncapturederror uncapturederror shouldn't fire after device loss #4017
• createRenderPipelineAsync/createComputePipelineAsync createPipelineAsync() doesn't reject its promise, even if the created pipeline is invalid #3296
• ... and Suppress error generation in create*PipelineAsync, clarify async steps #4752
• getCompilationInfo #^
• spec should suggest an unconditional console warning on device loss (since it's rare), so that the fact that most things continue to work without error doesn't confuse developers Implementation should always issue a warning on device loss #4052