Ahhh. ok. We’re kind of beholden to the rather narrow design of the GPU. It does certain kinds of math very well/fast, but the instruction-set is a bit narrower vs a general purpose CPU and as such only (really) supports certain kinds of programming-flow/structure.
What unreal offers is an abstraction-layer, the xml-based nodage we all tool around with. You could put a, for example, case, switch, decorator, etc type support at the xml level but it still has to be broken down and compile down to what the GPU can actually run (see above). So in that sense, not so much of one might want is readily supported.
Functionally what you are asking for is to take a material (rather it’s output) and use that as an input to another material/material-instance. Since the nature of the gpu-proggies are load/run, they don’t reach out to other programs being run on the GPU, they are kind of fire-forget, so mechanically, what you are asking for is to turn that material into a material function, use a blend-material-attributes, set an alpha which can be defined programatically; that is, mechanically your ‘decorator’. So far as I am aware, we need to pack everything you might want into the single material as that is what compiles down to a singular-unit.
It kind of has to be that way owing to the nature of the GPU, so, i I do understand correctly, my response is indeed your answer, at least inside Unreal.
What you CAN do aside from unreal, is look into a Custom node. It’s a node where you can directly paste HLSL code, and that certainly offers more options vs unreal.
It’s not like I don’t get you, but a lot of what we want in higher-level languages won’t break down to the GPU. Until the spec gets updated to include new stuff we’re left using what the GPU can actually do. Note that I am not an expert in HLSL, so take a look, there could be options I cannot describe to you being I might not be aware of them…