I was worried that might be the case. I believe that a reasonable refactoring could be done to efficiently support both OpenGL and Vulkan, but would be difficult to do without breaking existing code. Worst comes to worst, the current classes could become abstract super classes and the low-level native handle management could be done via subclassing. I’ve used similar patterns in a native rendering project I did for my day job a while back, although to be completely fair it was only used with different GL backends (no DirectX/Vulkan).
I think that depends a great deal on how that’s done. If the Vulkan renderer is working more or less the same as the current OpenGL one (but dispatching render jobs in place of state transitions), there’s not a great deal of benefit. However, if there were reasonably separated Vulkan/OpenGL renderers then I think a highly performant Vulkan renderer is within reasonable grasp. I’m personally not all that interested in a codes-like-GL-renders-on-Vulkan type feature - it’s throwing away huge possible gains.