In regards to JBullet, you can find several threads here talking about it, but to summarize, it does not support all the features of native bullet, has several major bugs that need to get fixed, and no one is likely to fix them because we have other physics engines that do work. (Also considering that many of us are now using Minie, I personally would like to see bullet removed from JME4 altogether and make Minie the official third party physics engine, but I know there will be a lot of people against that)
As for OpenGL and Vulkan. There are many things that work very differently in Vulkan than OpenGL. Vulkan is much better suited to multi-threaded environments. It also has a unified environment where there are no differences between mobile and desktop (in theory).
As for implementing both:
I think that it is possible to do. The major things that we use in jme are objects such as Nodes, Spatials, Geometries, and Lights for organizing the scene graph. We already have an opengl engine for doing this. If we create an abstraction layer between ‘our’ side of jme and the ‘rendering’ side of jme then in theory we could have both. With that said, it is not as simple as just having vulkan calls instead of opengl calls. The vulkan layer would have many moving components to take advantage of its power. I am not very familiar with the inner-workings of vulkan, and I am hoping we have someone here who is, or can get someone.
Ideally we do not cut opengl support, at least not in JME4 (perhaps 5?). I see no reason to remove something that works and is still widely used. But by supporting Vulkan we can gain access to new technology that is not getting supported in opengl (I will use my favorite example of ray tracing shaders).
Again, I know very little about how Vulkan actually works, and I am by no means an expert on opengl. It would be great if someone with experience in opengl can give us a opinion on if we can abstract the rendering system away from
jme-core and break out rendering support into