I was just thinking, it's actually not easy these days to get into gamedev without using an engine.
Beside things like SFML or rayLib there is not much around to give you some gfx to get started.
Consequently everybody is using engines, and gamedev is not longer development but just content generation, as i like to say.
This has to stop. All game i see are the same. They are boring. At this point i do not even try new games anymore. It's a waste of time. They all *. They say they make AAAAA games now, but i say no thanks.
It is so bad, i even have motivation issues for the first time in my life.
But maybe at least a tiny minority of people is still willing to learn gamedev from ground up, so they can come up with new things instead cloning former successes and adding one more A.
And if so, a physics engine with a simple renderer would be much more useful than Godot.
So if i were you, i would target this new generation of devs, which are the survivors of the upcoming video game crash.
In this sense, there is one request / proposal i could make: Debug visualization. I have never seen a library for that.
This is what i see when working on the ragdoll:

- Capture.JPG (105.11 KiB) Viewed 4243 times
I do visualizations all the time. It's some work but it really helps to understand and verify.
For rendering i support the following primitives:
Point(x), Line(x1,x2), Vector(x,v), Arrow(x,v,size), Circle(with given axis or aligning to camera), Cone
I can also print text at a given position, which is super helpful. (using ImGui)
And i have a plot which you see on top of the image, graphing curves where i add a data point each frame. For the ragdoll the plot is really essential, but i rarely used it elsewhere.
Then i have a window where i see my debug log, so i do not need to have a console window or look into a file.
To me those debugging tools are absolutely essential, and i use them for everything i do.
It's key that they are easily available from everywhere.
I saw you have a visualization method in your joint base class. That's good software architecture, but it's also too cumbersome for debugging. I do it differently: Just putting a Vis::RenderPoint() call into the code i'm currently working on. This generates debug clutter you need to remove later, but it's convenient. (ImGui also is an example of this kind of workflow - you can put ImGui calls everywhere and don't have to initialize something up front.)
Maybe you could provide such debugging tools as well. For me they are part of my application framework.
But that's really just an idea, not a request from my side.
Another thing i think would help is debug visualization of your collision geometry.
You provide related tools already and i use them. Your spherical triangles for round shapes look very nice.
But maybe you could make this easier so users need to call only one function for the whole scene.
Personally i can draw this either solid or wireframe, and each object gets a random color.
The colors help a lot compared to your monochrome collision display from the sandbox.
To me this collision geometry is all i want to see. I would develop most of my game with this kind of gfx. No need for distracting textures and lighting. I care about that only later when starting with content for the game. (But simple shadows can be helpful to visualize contact.)
Looking at detailed game models is not helpful for me, because there always is the paranoia of a mismatch with the collision shape.
On gamedev.net i often see progress on the Matali physics engine, which has a simple renderer. And recently even lights became part of that. 'Physically accurate lights' ofc., although i don't know what this claim is based on. But maybe this goes a bit in to the direction you have in mind, and you can take a look. Running the engine demo feels like playing a game. A real game, not those awkward inversed mouse camera controls rocket scientists like you use.

If you care about presentation, this might matter the most.
(I'm at least a bit closer to a fast walking ragdoll...)