It is not a next generation OpenGL, unless one wants to become an expert in driver and compiler development on top of mastering graphics programming.
Currently Khronos answer for those that don't want to become such experts it to stick with OpenGL, the problem is that is isn't gettting much updates beyond 4.6, and Vulkan is not getting a more developer friendly API.
Most devs will be better by choosing a middleware engine and just check the respective box of the desired graphics API backend.
I think expert in driver and compiler development is too much. It takes a lot more to get started, because it doesn't assume any defaults, but then it isn't too hard as long as you venture into topics like multithreading, but then in OpenGL you never went into multithreading in the first place.
I think the best middleground between OpenGL and middleware engines are translation layers such as gfx-rs and bgfx, which offer a low-level but userfriendly API and can compile to several different graphics API backends.
The theory was that OpenGL or any other API of that kind is reasonably easy to implement on top of Vulkan, providing very long term support and compatibility for OpenGL-based applications.
In practice, like 15 years ago, you can use Mesa3D which remains as comprehensive and unexciting as ever with constantly improving performance thanks to using Vulkan.
In the more mainstream part of practice, rendering engines get rid of OpenGL to use Vulkan because it's usually better.
Unfortunately the API update model hasn't changed much from OpenGL it seems ;)
...not talking about the idea to first test out new ideas in vendor-specific extensions, and then elevate them to the core, this is definitely a good idea - but about stacking new stuff on the previous API version, this approach is what turned OpenGL into the heap of accumulated cruft it is today.
Direct3D instead was a new API with each new major version, which in the beginning sounded insane, but turned out the better decision in the end because that made it possible to discard the cruft (the crucial part is that old API versions are frozen but still supported).
OpenGL deprecated the cruft in 3.0, removed it in 3.1, then added a way to get it back with the compatibility profile in 3.2. Turns out a lot of people still wanted that cruft and they were a big enough market that people listened to them. I believe it was CAD software asking for this which on Windows is the only major user of OpenGL.
Direct3D is mostly used for games so if your new game has to use a new API that's not _that_ big of a deal. You don't start from scratch every couple years with regular software though.
LOL. It is not the nextgen version of GL. It is a tool that would let you make your own OpenGL. It is way too low level and takes insane amount of work comparatively to OpenGL/DirectX. Sure big engine developers would love it. Smaller guys like myself: not so much.
That's the difference right here. If you are in business of making engine then yes you can benefit basing your engine on something like Vulcan. To me: I am not exactly doing games/engines. I do use hardware accelerated graphics for some other type of development. OGL/DirectX are already a nuisance enough for me (just a friggin too that I want to use and forget). Having to go even lower level will not make me any happy at all. Well that is unless I find suitable rendering library. Hopefully some candidates are available now, just have to find time to evaluate.
Currently Khronos answer for those that don't want to become such experts it to stick with OpenGL, the problem is that is isn't gettting much updates beyond 4.6, and Vulkan is not getting a more developer friendly API.
Most devs will be better by choosing a middleware engine and just check the respective box of the desired graphics API backend.