The point was explained above, and you get it. Godot case demonstrates it more than clearly that having a common API is good for developers. You simply avoid admitting that lock-in is bad - all this talk about "IP" has no relevance to the issue.
So let me put this in another way, neither OpenGL or Vulkan are a common API, beyond the basic step of putting a triangle on the screen.
Any production grade, cross-platform engine, has so many extensions and workarounds for drivers and cards, that each code path ends up looking like a different API is being used.
They are common only on paper, write once, patch everywhere.
In fact, if you want to use OpenGL in a way to avoid such mess, OpenGL 3.3 is probably still the best target to hope for, with all the constraints that it entails as legacy version.
Just like on mobile devices, as Godot was forced to redo their engine, anything beyond OpenGL ES 2.0 is more headache than it is worth.
Google has made Vulkan a required 3D API on Android, because most drivers outside flagship devices are unusable and they hope that via this option to force OEMs to actually provide something that developers can actually make use of.
> So let me put this in another way, neither OpenGL or Vulkan are a common API
OpenGL is legacy case, so no point in bringing it. Vulkan is the only common API, there is simply nothing else for that role. With all your talk about how "great" proprietary APIs are, none of them ever can be common, because they all are the total antithesis of it - their goal is lock-in in, not something that helps developers reduce their work duplication by providing the standard.
So so much for "great IP". They are DOA basically in this sense, and exist only because walled garden owners force developers to use them by not providing them a choice.
Your personal advocacy for lock-in is also more than questionable.
According to Khronos, OpenGL is still the API to go when one doesn't want to deal with Vulkan boilerplate.
Middleware is the common API.
Taking advantage of raw performance from hardware, exposed with SDK tooling that Khronos has never offered.
Basic stuff like math, loading textures, material description formats,...
Instead every newbie has to go through the challenge of creating their own little engine.
My advocacy is based on real experience, having been IGDA member, attending a couple GDCE and Design School meetups, having had the opportunity to visit a couple of well known AAA studios.
So I have enough hours talking with such devs to know what they care about.
Being religious about 3D APIs is usually not on their agendas, rather getting customers, turning game ideas into IP that they can explore across various commercial channels, consulting opportunities porting game engines, how to take advantage of "whales" and such stuff.
