This is the place to post general stuff concerning the game. Want to express your love for hoplites or find people to play the game with? Want to share your stories about matches you have played or discuss historical connections to the game? These and any other topics which are related to the game, but don't have their own forums belong in this forum.
Do you have any questions about modifying the game? What will you need to do what you want to? What are the best techniques? Discuss Modifications, Map Making, AI scripting and Random Map Scripting here.
Forums for decision-making on issues where a consensus can't be reached or isn't sufficient. The committees are chosen from among the official team members, but to ensure an open and transparent decision process it's publically viewable.
Yes, that was an origin point. But it's not a silver bullet. Because the another layer of abstraction reduces flexibility, adds limitations and may reduce performance, because of many differences in backend APIs. We can't just add a IRenderer with methods like drawTriangle. Theoretically you can do this, but it would have a significant performance lose.
You may add abstraction structures (like octree for frustum culling) that work for all types of backend. But some backend dependent stuff won't work easily. For ex. shaders, you need to use universal language or use some language converters. Which means another layer of limitations.
So, what we could do (not a full list):
1. Use own graphics engine
a) Use the only one backend API (like Vulkan or GLES) with some third party libraries (like libangle for GLES) that convert these API calls for other platforms (other than supported platforms by this backend).
b) Use multiple backends (like you suggested) with run-time or compile-time backend changing.
2. Use third party graphics engine/library:
a) Use a complete game/graphics engine (like Godot).
b) Use a complete graphics library that has own stable API with own shader language.
In only my opinion I'd prefer the 1a or 1b but with not more than 2 different backends, like OpenGL + Vulkan. Because they're Open-Source and present mostly for all platforms (through third-party libraries). Because it's most interesting for a graphics programmer: you don't need to support a lot of backends and you have enough power of the backends.
But! It means that we need to handle some low-level stuff by ourselves. Like GPU blacklists, driver specific bugs (like our Intel crashes), and so on. That's harder to support. Complete engines have own problems too, they have less flexibility/performance or small number of supported platforms (some engines already dropped <= GL2). They may change their license or stop support it.
Actually it's not the easy question. That's why I suggested to not rush inside rewriting all graphics stuff (while we somehow support most platforms) and refactor all related stuff first.
I think the main task now is to collect and isolate most of GL code in some specific place (not just call them through simple proxy functions). That'd be useful for any way that we'd choose.