you should be careful with bold claims, especially if you don't have a great depth of knowledge (everyone should believe this...)
i commented on the post.
(don't let me nay-say too much. you have done a really wonderful thing here. that is what matters most.)
also the idea that old desktop OpenGL is valid any more grates and encourages using it... its something we would like to have died its death 5-10 years ago when it was already out of date.
its also the case that all of the 'desired' functionality for 3d which is 'missing' is equally applicable to 2d and so equally missing from the API. there are no rotations 'out of the box', no aspect ratio correction, no texture mapping, no anything. this is what we expect from a low-level API, the minimum set of features required to make the hardware do the job - not an encyclopaedic library of derivative functionality (this is the place of a higher level library than the hardware interface).
i think the author has confused it being a low-level API with it being 2D. these are not the same. its just as devoid of features regardless as to what space you are rendering in... i can really understand it if coming from a web background where the stack is gigantic and "low-level" is an utterly foreign concept.
(also, in my defence, i didn't go into great detail, since i commented on the post itself to avoid polluting HN with a conversation thread)
It is completely up to the user whether the position data for the triangles is given in 2D coordinates from the start or in 3D coordinates and then transformed to 2D coordinates in the vertex shader.
The fact that it makes it fast to do the math for 3D, does not make it a 3D API.
also, please don't confuse OpenGL circa 1999 with modern OpenGL. the features removed in ES were considered bad practice 10-15 years ago... i do disagree with removing default shaders (our beautiful flexibility is now relegated to mere boilerplate) but i'm sure the OpenGL ARB had a good reason behind that choice (reducing driver responsibility, reducing points of failure etc.).
also, what is never up to the user is the perspective divide. if a naive user is not aware of this particular, very 3D specific gem, of the hardware/API then he will end up with subtle bugs and maybe even struggle to fix them due to the incomplete knowledge...
its got nothing to do with performance.
Also, what's the final verdict on Fast InvSqrt()? Is the optimal magic number Q3's 0x5f3759df, Chris's 0x5f375a86, or your 0x5F375A7F?
the differences are tiny though, and there are other measures that can be used (which will result in different constants)
in any case, on most modern hardware it is not relevant since there is some lookup based instruction that is more accurate, and faster.
the problems here aren't enormous, a smart programmer will work them out for himself, but they are misleading. i think there is some confusion just because this is a low-level API, essentially a hardware abstraction layer, but the user is expecting high level features like a complete maths library. (maybe?)