I'd like to see a reasonably-standard C++ API specification for at least a few graphics-related things (and perhaps more over time), but am not sure if writing a graphics API with the sole goal of eliminating all other APIs or libraries, would make any sense. The people with whom I've talked to, some of whom have done work on P0267/io2d, don't seem to be explicitly aiming for this either, but perhaps I've missed something.
I'd be happy to see vec2/vec3/vec4 style APIs in the C++ standard, too. P0267/io2d does have some support for this, although I think it could certainly stand to get some love + attention!
I agree that having a standard with a common subset of widely-used features would be of value, however, I'm suspicious of the claim that it could cover "95% of use cases". Are there some specific use-cases that you have, or had in mind?
The authors of the recent, P0267 C++ graphics paper (aka "io2d"; latest revisions getting posted to https://github.com/mikebmcl/io2dts/tree/master/papers), as far as I've seen (online, mostly), aren't interested in making a "toy" API. Many, if not all of them, want people to be able to do 'real' work with it. They've also seemed willing to accept constructive feedback on it, and are cognizant that there is a good amount more work to be done, if something useful is to be a result!
There is, I think, room to work on different C++ features in parallel. A graphics expert isn't necessarily going to want, or be qualified, to lead a charge on all future, non-graphics features.
In terms of 'other languages have it too', here's one platform/standard that has it: HTML5. It's Canvas API is pretty widely available, although in practice, perhaps only with sufficiently powerful runtime-processing power.
Regarding software renderers, I'd argue that these are still useful, in some use cases. I've worked on some projects whereby a constexpr/compile-time canvas-style implementation would have been useful, I imagine.
SDL2's render API can use GPU acceleration, however its feature set is rather limited. This is plenty for many, however is incomplete for others. I've heard its feature set be referred to as 'SNES-level graphics', or something to that effect, from at least one SDL-internals dev, something which I'd also echo.
A little off topic but how is SDL nowadays? I used it for a quick and dirty game back in my college days (13-ish years ago?) and I really, really enjoyed using it. It was very approachable and I could build it on my Windows and Linux PCs.
A suggestion: wrap the bulk of content in platform-specific .cpp files, with pre-processor guards that'll check for platform. This should allow the library to be imported into other projects, simply by importing all .cpp files, and adding a path for header-includes. With that done, adding support for extra build systems becomes an optional, albeit nice-to-have addition, but by no means required.
I believe the thought was that, for many languages, there is an additional, standard runtime, which is not always remove-able from the language itself, which may not always be of a trivial size, and which is not guaranteed to be already available on a client machine.
But to what degree might this 'meta-API' be different than WebGPU/JS? Might this effort effectively end up creating two, new APIs, each with different vocabularies (one for JS, another for C or C++)?
The whole point of Vulkan/Metal/DX12 is that since GPUs have their own MMUs it's totally OK to seg fault your own process from the GPU side. You just crash your process, but you don't take down the system.
That line of thinking doesn't really translate well to a JS API.
I'd be happy to see vec2/vec3/vec4 style APIs in the C++ standard, too. P0267/io2d does have some support for this, although I think it could certainly stand to get some love + attention!