It made me wish to be able to do a MAP-EACH on a TEXT! and have the body return either a NULL, a CHAR!, or a TEXT!...
>> map-each c "123" [ case c [ #"1" ["one"] #"3" [#"T"] ] ; don't have any match for 2, so fall through with null ] == "oneT"
The ability to go element-by-element and map to potentially 0, 1, or many elements seemed like an appealing thing. Enough that I wondered if MAP-EACH should splice by default.
Splicing is strictly more powerful, because you can put things into a block:
>> map-each x [a [b c] <d> e] [if not tag? x [x]] == [a b c e] >> map-each x [a [b c] <d> e] [if not tag? x [reduce [x]]] == [a [b c] e] >> map-each x [a [b c] <d> e] [if not tag? x [:[x]]] == [a [b c] e]
It would seem to suggest you'd want an /ONLY for convenience.
There are benefits. But as with APPEND doing splicing when it's not asked... it's a likely source of bugs. This category of bugs is probably one of the biggest.
Another side of the argument is to go with MAP-EACH as it does today, producing a BLOCK! always. If you always get a block, then you get to make up the step which coalesces things.
I've made arguments for this line of thinking in the past. It seems a bit wasteful to always be producing a BLOCK! from a large text string, then merging it together. But perhaps the argument made against /INTO applies here too...that anyone who cares wouldn't use MAP-EACH?