One strong argument at the evening session was that not everyone has access to non-standard libraries, which in my opinion is a ridiculous argument. If your work doesn't allow non-standard libraries, then it's time to move on, we really should not feed the companies with the "not invented here"-syndrome.

Another argument many people brought up is that it would allow C++ to be more usable as a teaching tool or a few shared their stories of basic graphic programming which eventually landed them in C++. But I really don't see why the standard needs a toy API. If people pick C++ as their learning language, they should be able to learn how to use another library, since that's very much part of learning C++. Besides there are more complicated concepts in C++ than having to follow some dead simple tutorial on getting another library working. And if you go down the teacher route, then it's really no issue setting up a library for those learning.

And finally there's the argument of "other languages have it too". Yet, I haven't really seen examples of that. I think .NET has something like that, but then again .NET also has a full API for window creation and tons of other things. Maybe a simple drawing API is a good idea, but first we'd have to add other things to the standard.

All in all and seeing the evolution of OpenGL, I simply don't see a reason why the C++ standard needs a simple drawing API right now. There are tons of other things that are way more important and should be added first. And once you get to a standard drawing API, what good is it, when you still have to write custom/platform specific code just to get an actual rendering surface (aka window) on screen?

And one final point is, who needs a API that is designed for a software renderer? What year is and who is still running software renderers?