Bug: Warnings in "inactive" branches stop workflow

At least that's what I think is causing this very odd behaviour...

So I have some writer node that is told to ignore the existence of a file and to just overwrite it. It still wants to warn me, though, which is ok. The writer is in an inactive branch of a case switch. If I shedule the End Case, the Writer is configured with a URL from a flow variable and cries for help, because it warns every time it is configured with a new file, regardless of everything else. Which is still ok, because who knows what silly old me is trying to do. But this warning is interpreted as a kind of error somewhere (but not in the logs as far as I can see) and this error travels downstream and and un-shedules everything, including the End Case. (The active branch of course is still executed, because it's not downstream from the writer.) Now that the warning has passed it, I can just re-schedule the End Case, and it is still executed as expected, as if nothing ever happend. So if my switch where on the top level and everything was done manually, that would be odd, but ok, I'd just have to execute it twice in a row. But if it's inside a loop or somewhere else unaccessible, I have a serious problem.

Oh, and it's only a warning, so try/catch sees no reason to do anything about it. The only workaround seems to be to work around warnings in switches. Maybe some clever trickery with the Active Branch Inverter would help, but I can't see how.

I've tried several of the "standard" case- and if-nodes and also the Vernalis variants with flow variables, all with the same result.

A little bonus I discovered while searching for the cause of this behaviour: Java IF can be broken with return Math.random()>0.5 ? 0 : 1;. I can see many reasons why that might be the case, but no good one.

Ok, I'm gonna back off. It's not the warnings. It's something else. My edit history influences the behaviour of the nodes. The same workflow seems to behave differently depending on if I execute it directly or edit it, undo, and execute from the same state as before. In any case, the inactive branch influences the scheduling of the End Case. Something is seriously broken in the switches...