Instead we have a third graphics standard (after canvas and WebGL) fully incompatible with the previous two that does exactly that: abstracts the OS graphics stack in a new layer

It's not perfect mind you (e.g. baked BindGroups may be a bit too 'rigid'), but it's still a massive improvement over WebGL in terms of reduced CPU overhead.

> except WebGL, which is abandoned.

So it can be abandoned

I suspect WebGL was different, since it was based on the old OpenGL/DX9 way of doing things, so a clean break was desireable. But I honestly am not that knowledgeable in neither graphics programming nor WebGL history, so take that with several grains of salt.

Google refused to support WebGL compute based on OpenGL ES 3.0 compute shaders, citing WebGPU alternative, and there are still quite a few capabilites from OpenGL ES 3.2 missing from WebGL.

Some of which still not available in WebGPU 1.0.

It's not a nice API, but it is common and vendor neutral all the same. A lot moreso than WebGPU is, even, since Khronos has a much more diverse set of inputs than the web does. See eg all the complaints about Chrome dominating the web discussion, and even beyond that you only really need 3 companies on board. Khronos has significantly more at the table than that.

WebGPU outside of the browser not only suffers the pain of being yet another incompatible shading language, it is also offers the additional possibility of having code incompatible with browsers WebGPU support, due to the use of extensions not available on the browsers.

First of all, if one depends on SPIR being present, then a SPIR to WGSL compiler needs to be present when deploying to the Web part of WebGPU.

Secondly, it will be yet another extension spaghetti that plagues any API that Khronos has some relation to.

Or flipped around, it creates an incentive problem where none of the vendors see much benefit in doing R&D anymore, because browsers aren't content to merely abstract irrelevant differences, they also refuse to support vendor extensions except for their own. No point in adding a cool new feature to the GPU if Chrome/Safari insists on blocking it until your competitors all have it too.

Luckily the GPU industry is driven by video games and nowadays AI, industries that don't write code using the web stack. So they'll be alright. Still, that same incentives problem exists in other areas of computing that sit underneath the browser (CPUs, hardware extensions, operating systems, filesystems, etc). Abstractions don't have to erase all the differences in what they abstract, but people who create them often do so anyway.

However, I think what GPU programming needs at the moment is better ergonomics, and code portability is a step in the right direction, at least. Currently it's quite a bit more annoying than CPU programming.

(But of course like you say this doesn't detract from the native code apps that want to debug, support, bug-workaround, perf-specialcase their app on N operating systems x M GPU hardware archs x Z GPU APIs, x Y historical generations thereof)

Why can't a common graphics API evolve through well researched and heavily scrutinized proposals? The amount of societal loss of efficiency in having competing specs that do the same thing in slightly different ways, but require immense effort to bridge between is truly vast.

The incentive to innovate comes from limitations with the current spec. That doesn't change just because there's consensus on a common base spec

Stifled innovation in what context? I wouldn't describe the web stack as an industry consensus given the rejection of it (for apps) by mobile devs, mobile users, video game devs, VR devs and so on. If you mean within the web stack, then, well, there have been plenty of proposals that died in the crib because they couldn't get consensus for rather obscure reasons that are hard to understand from the outside. Certainly, there were innovations in the earlier days of the web when it was more open that have never been replicated, for example, Flash's timeline based animation designer died and nothing really replaced it.

Fundamentally we can't really know what cool things might have existed in a different world where our tech stack is more open to extensions and forking.

Why can't a common graphics API evolve through well researched and heavily scrutinized proposals?

Why can't everything be done that way? It's been tried and results are a tragedy of the commons. These ideas don't originate in the web world. The incentive to develop the tech isn't actually limits in web specs, that's a decade+ after the innovation happens. What we see is that the web stuff is derivative and downstream from the big players. WebGPU traces its history through Vulkan to Metal/D3D12 and from there to AMD's Mantle, where it all started (afaik). So this stuff really starts as you'd expect, with some risk taking by a GPU designer looking for competitive advantage, then the proprietary OS design teams pick it up and start to abstract the GPU vendors, and then Khronos/Linux/Android realizes that OpenGL is going to become obsolete so they'd better have an answer to it, and then finally the HTML5 people decide the same for WebGL and start work on making a sandboxed version of Vulkan (sorta).

N.B. what made Mantle possible is that Windows is a relatively open and stable environment for driver developers. Ditto for CUDA. They can expose new hardware caps via vendor-specific APIs and Microsoft don't care/encourage it. That means there's value in coming up with a radical new way to accelerate driver performance. In contrast, Apple write their own drivers / APIs, Linux doesn't want proprietary drivers, ChromeOS doesn't even have any notion of an installable vendor driver model at all.

     the best way to code cross-platform graphics outside the browser. 

Meanwhile on the GPU front you don't have much in the way of large, good middlewares to abstract away the underlying API. OpenGL used to be OK at this, but now neither platforms nor Khronos wants to touch it. Vulkan is "portable" but it's like writing assembly by hand, it's ludicrously complicated. WebGPU fills the role of essentially just being GLES 4.0. It won't be fast, it won't be powerful, but it doesn't actually need to for the long tail of things that just want to leverage a GPU for some small workloads.