Update: (discovered very shortly after this was written)... the situations in which it does work aren't interesting...basically all the situations you'd want it for are the ones where it can't work. Short-circuiting doesn't know the shape, e.g. if action? :x and x [a] [b] [c] [...] doesn't know what the arity of X would have been if it were an action.
So it doesn't know how much to skip. Ultimately AND and OR had to use BLOCK!s and GROUP!s on the right hand side to short-circuit, but the result is pretty good anyway. So it was a good line of thinking, but DON'T was accurately named. DON'T do it!
Original post preserved below, namely because Discourse won't let you delete topics...
Imagine an operator called DON'T, that works something like this:
>> code: [print 10 + 20 print "Hello"]
>> code: don't code
;-- outputs nothing. heh heh
>> probe code
[print "Hello"]
Basically, it's the anti-DO/NEXT. It shifts the evaluator into neutral, and skips one unit of work.
This could likely power short-circuiting forms of AND, OR, NOR...
and: enfix function [left [any-value!] right [any-value! <...>]]
if not left [
don't right
false
] else [
truthy? take right
]
]
Since failure will be common, one might make it conditional to provide more informative errors. So you get the new position returned or a BLANK! if it got an expression it couldn't calculate through the arity of without running it.
and: enfix function [left [any-value!] right [any-value! <...>]]
case [
left [truthy? take right]
don't right [false]
]
fail [
"Right hand side of AND can't be variadic expression." |
"Use ALL [...] or put the variadic expression in a GROUP!" |
"(or if non-short circuit and prefix is okay, use BOTH?)"
]
]
And if that isn't cool I don't know what is. 
If one wanted to be perfectly parallel to DO then it would actually be something like DON'T/NEXT, but then there wouldn't be a whole lot of point to DON'T-ing without a /NEXT, besides I guess checking it for if it is well-formed. But it wouldn't be 100%, because this won't work for any variadics in the block. (They'd have to be put in GROUP!s.)