The approach taken by AAA game engines, although nowadays it looks more like a bunch of abstract classes/interfaces, depending on the language.
When you look into a game engine, typically 3D API abstractions are like 10% of the whole codebase.
You can look at this article: https://dolphin-emu.org/blog/2017/07/30/ubershaders/ for an example how console graphics programming differ.
Middleware designed for games don't allow nearly enough flexibility to handle all the possible edge case that can arise. Console gpu (and graphics api) and computer gpu don't map one-to-one and they need all the feature and support from the underlying api that they can get for replicating the console way of doing things, supporting a new graphics backend is a lot of work for this reason. middleware try to abstract common pattern and flows, but every console is quite unique (in some way) middleware are not build for that and often are (a form of) a lowest common denominator for graphics api. Which is fine... for games.
edit: some clarification
Even if you stay, lets say OpenGL only, there are multiple execution paths with driver and graphics card specific code paths.
3D libraries like OpenGL/Vulkan are only portable up to a certain extent.
When you are coding at the ultimate performance level, you are also going into that rabbit hole of graphic card specific code paths and driver specific extensions.
So, it is hardly different than having your own plugable abstraction layer.
I wouldn't mind to contribute if paid accordingly.