This is not really a suggestion, as I'm already working on it (in my own sandbox not in the official openxcom repository): people that are on IRC already know all of this, they are already totally bored with my rambling.
But I just wanted the forums opinion or comments too, regarding the implementation of it.
So the idea is to keep support for SDL, Pallettes, 8bit graphics, software blitting, 320x200 - the oldskool stuff.
But on top of that have the option for OpenGL, truecolor graphics, hardware blitting and higher resolutions.
Apart from the differences in intialisation, support for both opengl/sdl is done by abstracting the Surface class and creating two new implementations: SDLSurface and OGLSurface. The second one will load the surfaces as textures into video memory: blitting (and shading) surfaces will be done in video memory. (when it makes sense, because video memory has its limits)
New blitting functions, text & simple geometry rendering functions will have to be written in openGL versions.
I got the basic lines and pieces of code for the most part. I must give credit to the FIFE engine for it, as I take a lot of inspiration from there.
For testing I'm currently using UFO:TTS's graphics (which I converted to PNG, because I wanted to make sure SDL could handle that format also).
On the geoscape part we got another fun new toy to play with: drawing teh globe in opengl. In theory it would dramatically simplify the globe code (also the shading of the day/night cycle, which could be done simply by adding a rotating light to the scene), while dramatically increase the fps.
However I did not try anything on that front yet... it's just theory and ideas.
How are you going to handle palette rendering under OpenGL? Building up a bunch of smaller buffers via software rendering, then uploading them as textures will be slow for higher resolutions.
When I was thinking about how to use OpenGL as a rendering backend, I found a couple of articles about talking about how to implement palette rendering. The thought was you would have two textures, one that is 8 bit containing a color index for each texel, and the other of higher bit depth, containing your color values. You then write a pixel shader that did the look up of the color index for the current texel in the color value texture. I never did get around to implementing it, so I don't know how it would perform.