Tldr: similar to Vulkan's recent revisions, it'd be nice to be able to reduce overhead of creating pipelines, "pipeline combinatorial explosion" and recreating them in some applications, by allowing more
hopefully-commonly-supported dynamic state, like depth test or blend mode.

The original research of pipeline state design in #26 is now slightly out of date: the set of originally supported dynamic state fields had 9 items, but by Vulkan 1.3 it has several dozen, including common items like stencil or depth compare test operation. This is provided by now-required extensions VK_EXT_extended_dynamic_state and VK_EXT_extended_dynamic_state2. The next (currently optional) extension VK_EXT_extended_dynamic_state3 adds more dynamic state like blend mode. This admittedly complicates the API by having two ways of doing the same thing (and having the implementation track these two ways), but clearly they considered it worth it given these are being slowly moved into the core spec.

( digression: there are also other extensions like (required in 1.3) VK_KHR_dynamic_rendering that reduced focus on RenderPass objects, and a very recent (optional) VK_EXT_shader_object that essentially abandoned pipelines and re-added dynamic shader binding. In particular, the last one's proposal contains a rationale claiming the pipeline design to have - in hindsight - failed. )

Our application (which works as a game engine and can receive state changes at runtime - this can't be redesigned) is also hitting the same kind of issues relating to the number of pipelines bloating application load time, and some cases forcing us to recompile pipelines at runtime. Being able to change some of this state - like blend mode or depth test - dynamically would let us mitigate that significantly. And from what I understand, at least some of this dynamic state should be widely supported across vendors.

What's your opinion on this kind of API extension?