While no one has really commented on this, I think my mind is made up:
It's more intuitive and useful to NOT run the plain GROUP! when the triggering condition is false.
Mechanically, Ren-C has long been able to make a different choice from historical Redbol here, due to changing the parameter conventions to facilitate soft-quoted branching.
...speaking of which, my mind is made up on that, too:
Soft-quoted branching is now foundational. I use it all the time, and like it. And it's an even bigger efficiency advantage in stackless, where you can provide a value directly and not require pushing a stack frame.
So the decision is made.
What if You Want the Branch to Run Anyway?
Right now the answer is to use a GET-GROUP!.
>> branchy: func [flag] [either flag '[<a>] '[<b>]]
>> either true (print "a" branchy true) (print "b" branchy false)
a
== <a>
>> either true :(print "a" branchy true) :(print "b" branchy false)
a
b
== <a>
The reason it works is that right now, GET-GROUP! unconditional processing is done by the soft-quoting parameter convention. So things like EITHER don't have a choice. They receive a plain GROUP! quoted, but a GET-GROUP! will have ran before their code starts.
I'm less sure about this, and it ties into a lot of questions about parameter conventions and things-that-start-with-colon. Some of the more interesting ideas I have for GET-XXX have to do with a meta-like convention that would allow the implementations of things like APPEND to be able to reduce-and-splice:
Beating REPEND: A New Parameter Convention?
So I'm unsure of how what might come out of that could affect these choices. If APPEND expects to receive things like a GET-BLOCK! unadulterated so it can blend reducing with appending, they might expect GET-GROUP!s to be passed as-is also. That might juggle things in these parameter convention ideas.
But I doubt anyone was really clamoring for the ability to run code in groups for branches that aren't taken. If you are deeply affected, feel free to write a long sad essay here. 