WebGL and OpenGL ES are pretty much OpenGL. Formally they are different standards, but they are based all in OpenGL: if you know one, you know the others pretty well, which is what is important for developers as you agree in the second paragraph.

That is not news, and that has nothing to do with the state of OpenGL.

Please, stop spreading misinformation about OpenGL.

In any case, abstraction layers for macOS already exist.

And, going by your definition, if Apple only allows Metal, then no API will be cross-platform ever anyway.

Everything you discuss also applies to multirepo, but worse, because there no one enforces consistency across all the project and you will end up with a broken interdependency.

Then there is WebGL and OpenGL ES, widely used everywhere too.

So, no, it is not going anywhere. In fact, Khronos themselves have said so.

They haven't supported OpenGL for years anyway, so the fact they deprecate it now is irrelevant.

Are we really going back 30 years?

That is how it has always been done and is still done.

Yes, you can do it differently with an IL, but that isn't new either (Java, .NET, etc.).

In any case, with SVN you usually do not want to give write perms to everyone in all the tree, so you end up with effectively partitioned spaces, or you make several repos instead, or you put another layer on top. With Git, anyone can easily develop global commits.

If your code/project/company uses the dependency in any way in production and it is not a part of the base system (which should be reproducibly installed), you include it; either in source or binary form.

Why is the size a problem? Developers should only be checking out once. If your repo hits the many-GiB mark, then you can apply more complex solutions (LFS, sparse, etc.) if it is a burden.

False. It is having multiple repos what creates those problems and a huge graph of versions and dependencies.

What "processes" are you talking about?

A monorepo is just 1 repo. There is nothing more straightforward than that.

That seems like a build problem, not a Git problem.

> An additional source of strain is from people abusing the repo (checking in large binaries, third party dependencies, etc).

That is not necessarily abuse. In fact, it is a good practice in many cases!

> A third is when people try to do branch-based feature development, instead of the “correct” practice of only deploying master (or weekly cuts of master).

I am not sure what you mean by branch-based development, but I don't see why that would be a specific problem of monorepos.

Most of these benchmarks are not done to predict performance in a target machine, but to find out which is faster.

While there are dozens of things that can go south in benchmarking, how to solve them is not about applying advanced stats, but about understanding and eliminating the sources of noise.

Most benchmarks in CS can be done quite easily as long as one understands all the technology stack.