that sounds like some rather difficult abstraction work has to be done.
Yes and no. You can already put a different renderer in if that tickles your fancy, but it is limited to OpenGL, simply because the texture classes and the shader system expected OpenGL.
The solution is tighter coupling, eg. the renderer exposes endpoints that interact with the GPU, for example the GPU memory manager is managed by the renderer, so is the shader compiler and the texture uploader. Of course, it's not directly implemented in the renderer because, for example, a future OpenGL 13.37 renderer might want to re-use the texture uploader instead of re-implementing it.
So basically it introduces some more indirection, hopefully not noticeable to the users themselves. The high level texture class is still there, it just goes through the renderer to access the texture uploader and the renderers job is it to provide these GPU facing implementations. Lots of virtual classes.
Of course, as the user you can just say "give me just an OpenGL renderer", and then you can just call down to OpenGL if you need to without having to worry suddenly ending up on a Metal renderer and none of the OpenGL functions available. Or you implement multiple paths for eg. Metal, Mantle, OpenGL ES and OpenGL or any combination.
The whole rendering process is also restructured in a way that closer resembles the zero overhead APIs but that also works with the older OpenGL state system. Theoretically it should also be able to implement a legacy FFP OpenGL 1.1 renderer that uses glBegin() and glEnd(), but I wouldn't really recommend anyone doing that for obvious reasons.
