Should More Operations REDUCE (or COMPOSE) by Default?

For reasons that seem pretty good in practice, PRINT reduces a block given to it.

x: 10
print ["x is" x]  ; gives you `x is 10`, not `x is x`

An alternative would be that you needed to say print reduce ["x is" x]. But that seems laborious. Ren-C has GET-BLOCK!, and though that hasn't been entirely resolved for what it means, it opens the door to print :["x is" x]. That's briefer, but even that seems kind of lame compared to the historical non-colon-needing behavior with reducing.

What exactly was it about PRINT that makes it sensible to REDUCE? Can it be articulated what properties it has that distinguish it from something like APPEND, that would provide guidance to those making their own routines?

New Options with Modal Parameters

We now have modal parameters, and with that the ability to have evaluative routines receive @-forms and give them non-reducing significance:

>> x: 1020

>> print ["x is" x]
x is 1020

>> print @["x is" x]
x is x

>> block: ["x is" x]

>> print block
x is 1020

>> print @block
[x is x]

Just something to consider. I don't really have answers here, I was just throwing out the question.

Because it makes more sense to do so, and besides that, what else do you expect, for the suggested result "x is x", well let's say, does not compute :wink:

In the end this behaviour is just why everybody was using REJOIN instead of JOIN.

So where it made sense to Carl to have a JOIN and a REJOIN, from the perspective of having similar behaviour in functional behaviour in respect to naming of functions, making that consistent, practise has proven a different need.
We all could have been using the REPRINT function for years, neglecting the obvious PRINT because that did not reduce.
Naming functions is difficult. Best guidance I can think of now is to always be prepared to rename for a better alternative name has been thought of or the given name implies a (slightly) different generally expected behaviour.