@gajop disagrees with me, but I stick to my opinion, that the transition new primitives and the develop engine as a whole is not for every game. In fact it might be for only one or two or three of the existing or new ones.
Even though a good API wrapper will soften the experience, the Modern GL is still much more complex than the constructs we use in the maintenance:
- Every draw call requires an active shader.
- One needs to wrap their head around the concept of GPU buffers and generic attributes.
- I'm thinking about retained rendering mode, essentially draw tasks, that would partially eliminate Lua<->engine round-trips. If ever, it's not going to be a very easy API to use.
etc...
Those who are good as is might stay on the maintenance. The maintenance received very few changes over the past year and we know it's been a good fit for the most popular spring games. It's fair to say it's battle tested and requires zero effort to stay on as far as OpenGL, 32-bit builds, 32-bit servers, etc.
The aim for the transition is to not crash on the old systems without the needed (new for transition) OpenGL profile or extensions. Idk whether the goal is 100% attainable, but at least I'd consider such crash a bug. That said, I personally not gonna wrestle with all kinds of legacy. Old or 32 bit OSes, old or incomplete drivers, GPU potatoes, etc are not in the scope of my concern. The transition is the way to move forward towards develop and carrying too much legacy is unjustified.