I've watched the excellent talk from Yuriy and read a blog post multiple times already, but I still cannot find the answers to the questions I have.
I really like the idea of defining a graph of "virtual resources", it gives a lot of flexibility, maintanability, and ease of use (think about synchronization) in the long term. First, I thought that the easier way to solve my problem (described below) is to implement this system so that the graph building and the transformation to the actual graphics API wouldn't be done every frame, only when the conditions (eg. graphics settings) change.
However, extending the "only when the conditions change" statement to include game logic-related decisions, we get to a point where the frame graph must be rebuilt almost every frame. This is also what Yuriy suggested in his talk and I agree with it.
The main problem
In Vulkan the whole pipeline (with the corresponding render pass) must be pre-built. So the rebuilding of the whole graph every frame can be a bottleneck as I can imagine. The pipeline cache could speed up things (in theory) but avoiding sudden frame-rate drops is top priority. However, if a pipeline (especially the shaders) have not yet been built, it could cause a hitch up. And pre-warming the cache(s) with every possible permutations defeat the purpose of the whole system.
So I'm wondering if there is a way to keep the best from both worlds, rebuilding the whole graph every frame while avoiding sudden frame drops from pipeline creation.
If there is no such solution, what would be the closest thing to this kind of dynamic whole frame predefinition? Should I fall back to the rarely rebuild graph, and use another method to skip (sub)passes?
 FrameGraph: Extensible Rendering Architecture in Frostbite (GDC Vault)
 Render graphs and Vulkan — a deep dive (link)