Yep, polluting the code with multiple execution paths is a good thing.
You're... not required to use the extensions right? How else are you supposed to provide the _option_ to use _optional_ features? Feels like there's gonna be a branch in there somewhere. Lowest common denominator APIs are a non-starter for high performance graphics work.
Yep, hence given the size of a game engine, it is hardly any different having to deal with multiple flavours of OpenGL/Vulkan, or just use the best API in each platform.
Ergo middleware is the new cross-platform API.
Which code?
Game engine code, where testing for each extension and reacting accordingly leads to several if(){ } else { }, or a vendor agnostic interface layer, making the total development cost hardly much different than supporting multiple 3D API flavours.
The other option is waiting until all of the vendors have the ability that the extension provides and it has made it's way into the standard.
That option hasn't been taken away from you. And unlike OpenGL, you can't unknowingly be relying on an extension since they're opt-in. So what's the problem again?
Nothing, just false advertising on complexity improvement over OpenGL.
Anyway, middleware has won the battle of 3D graphics, what goes on the bottom layer is largely irrelevant to most devs.
It's not false advertising. Swapping the extension model to explicit opt-in is one of many pieces designed to help you manage complexity in a non trivial project for the reasons I've stated.
So far the amount of boilerplate to handle extension management and code paths in Vulkan samples shows otherwise.
Or, if you care that much, you can not have any of that and just not enable any extensions. Easy peasy
This is all a good thing.