We've had considerable time now to mess around with the option of letting IF take non-block branches.
As the person who advocated for it initially, I can say that I've been deeply on the fence about it...increasingly so, now to the point of thinking we should revert it.
The conundrum we wound up with is that BLOCK! branches are treated fundamentally differently from other kinds of values...they are executed as code. So if you see an expression that isn't a literal used as a branch, you are disoriented. As a reader, you are uncertain whether that expression's evaluation is the end of the evaluation...or if another will happen. And as a writer, you are going to be prone to making mistakes.
This problem is not new, and hits every new user when PRINT treats blocks differently.
>> x: 10
-- lots and lots of code --
>> print x
10
>> x: [format hard drive]
-- lots and lots of code --
>> print x
-- oops --
But I've long believed that is a weakness, and a fairly serious one at that. So we should go more toward finding solutions to that category of problem, vs. propagating it more widely and making the system more unpredictable on the whole...for limited value.
I know @IngoHohmann has spoken up for non-block branches, and @rgchris has too. Yet I'm afraid I'm going to recommend we abandon non-block branches, because they cause too much trouble for what they have truly gained us.
UPDATE: At the time this post was written, there were some symbolic constructs for using branches literally. Those symbols are retaken for other purposes, and soft-quoted branching provides a superior alternative, e.g. if condition '{string}.
I will also recommend CASE be changed to disallow non-block branches:
block: [print "this will be legal, too"]
x: 17
case/all [
1 > 0 [print "this will be legal"]
2 > 0 block
3 > 0 x ;-- not legal
]
Instead, one can use the CHOOSE primitive, which will never double-evaluate, and returns blocks as-is:
x: choose [
1 < 2 [print "returned as value"]
]
>> x
[print "returned as value"]