In order to be as independent as possible from the described multitude of hardware platforms and interfaces, QCustomPlot at least tries to use Qt APIs as much as possible, i.e. the QPainter framework with its various backends. However, this is not always possible so there still is some OpenGL-specific boilerplate code in a few of QCustomPlot's methods (not the many draw methods though, this is pure QPainter/QImage-based code).
From my perspective, the dust needs to settle first. Qt has attempted to integrate Vulkan some time ago, but it was still very low-level and basically only took care of the setup and teardown of the Vulkan surface via
QVulkanInstance. So switching over to vulkan would essentially mean that QCustomPlot needs to implement a QPainter backend for vulkan. This is better done by the Qt community, rather than in a specific project like QCP (and QRhi is a step in the right direction here!) Once that is done, I will definitely add the necessary boilerplate to run QCustomPlot's QPainter calls through that vulkan (or whatever else) backend, too.
Should it turn out that one of the new hardware interfaces becomes a consistent standard it may be thinkable to abandon QPainter calls and rewrite QCustomPlot's drawing methods in that standard. However I don't see such a interface standard coming up any time soon. For now it looks as the interface zoo has just become bigger by yet another contender.
We will see how it turns out once the situation is more stable. With a library as QCustomPlot that's used in so many critical and large applications, I favor stability and dependability over early adopting of shiny new technology, particularily with such far-reaching changes.