But BLOCK! is a valid IF product... this is a (currently) idiomatic way to make a block:
if condition [[data block]]
My point remains: in order to make a decision about whether that block gets used or not, you have to communicate a flag across the IF function call barrier. I've laid out my misgivings about that flag.
However... we could make the assumption that plain BLOCK! is never valid if not an argument to a function. So I could force you to say either:
if condition [$[data block]] ; if you want bound in current context
if condition ['[data block]] ; if you want unbound
And Ren-C does allow shorthands that dodge making an evaluator level altogether (literal branching):
if condition $[data block]
if condition '[data block]
So the loss of [[data block]] as a branch wouldn't be all that catastrophic....
But now this is a new evaluator flag to track... EVAL_FLAG_OUT_NO_DROPOUT. So BLOCK! would not set the EVAL_FLAG_OUT_IS_DISCARDABLE, but would set that flag. While $BLOCK! and 'BLOCK! would set neither...hence allowing dropout.
I'm skeptical this would be worth it. Introduces another nuance in the implementation...and makes you put decoration in source where you might not want it.
It feels too prescriptive (and if it seems too prescriptive to me, most other people will almost certainly think so).