I think this attempts to workaround limitations or inconsistencies in the API by introducing another API function on the GPUDevice. Instead we should address the limitations or inconsistencies without adding new API.

No, my claim is that both destroy() and simulateLoss() are useful for different things. destroy() to clean up resources easily during shutdown, and simulateLoss() for testing application behavior on device loss.

Specifically for the getMappedRange case on a lost device, should we just align the behavior to mapAsync when it is known the device is lost on the content timeline?

This would go against #1629. Of course, mapAsync already does, but I think that's more OK because it's async. That said, we did leave open the possibility of making mapAsync work on lost devices, too: #1629 (comment)
I think we mainly avoided it to simplify implementations, though I don't think the implementation is actually complicated.

I don't think it's a problem to provide things that are mainly for testing. Examples:

• The Web platform requires all platform exception types to be user-constructible. AFAIK the only reason this is globally required is for testing purposes.
• We probably wouldn't need the ability to catch validation errors using error scopes if not for testing. (See this doc)
• WebGL has WEBGL_lose_context.

Applications need to be able to test their code in the standard web platform. I don't think it would be reasonable if any or all of these capabilities were hidden behind some special browser flags: code couldn't be tested under the same platform that runs in production, plus everyone who writes software for the web would need to know about this.

Re: @kdashg's proposal that we change device.destroy()'s behavior so that it doesn't unmap buffers (instead of adding a new thing).

This is possible. It shouldn't have really direct impacts on application behavior. However a lot of WebGPU applications are pushing the resource limits of the system, so may be implicitly relying on device.destroy() to clean up memory used by mappings.

I don't think it's going to be a common problem, because mappings generally shouldn't live that long anyway, but in particular patterns like the "queue of mapped buffers" for data upload could have several large mappings alive that would no longer be cleaned up promptly, until applications update their code to clean these up explicitly.

Another side note: I was wondering if there's any conflict with triple-mapping, if keeping the mapping alive could have costs beyond just the raw memory allocation. I think there is no direct problem, since it always has to be safe anyway for the entire GPU process to crash. But I think triple-mapped buffers could be allocated in different physical memory spaces that are more memory-constrained than regular mappings, making cleanup a bit more important.