That's not possible, because the situation we have today is that proprietary APIs (D3D, Metal, CUDA) are pretty stable, whereas open APIs (OpenGL, Vulkan, OpenCL) are buggy or unsupported.

Because Khronos just outputs piles of paper and expects partners to do the necessary, while proprietary APIs provide full stack solutions with graphical tooling.

Metal is extremely buggy if you're pushing the state of the art. Patrick Walton has run into a number of very serious driver bugs in porting Pathfinder to Metal (he can reliably panic the kernel just by running shader code), and I've seen some as well, though today I'm working in Vulkan.

I'm hopeful for WebGPU in the future, not just for its features and expected cross-platform support, but because I expect a pretty thorough test suite to emerge, holding developers' feet to the fire to make their drivers actually work.

I find the use of "extremely" to be extreme here or too forgiving of problems that arise while using other APIs. There are all kinds of state of the art algorithms implemented on top of Metal. But anything improper can easily switch off GPUs, you can even do that with CUDA.

That's fair, I've certainly also had problems with Vulkan drivers from other vendors. So I'm not saying it's more buggy than other GPU platforms, but it is buggy, and it is more buggy than we expect of CPU-based language toolchains and runtimes.

Unfortunately, that's the situation. Though in the last couple of years, there is a noticeable increase in tooling on all fronts.

Because one of the top complaints is how Vulkan is found lacking versus proprietary API SDKs, even with what LunarG provides to Khronos.

WebGPU is going to be yet another layer to blindly debug without vendors graphical debugging tools support.

Maybe those that enjoy outputting pixels or debugging messages will be fine with it.