An excellent question... and a perfect one for the isotopic/atomic era. 
We could have isotopic blocks, and call them "splices".
Functions that took normal parameters would raise errors if you tried to pass them one, but ^META arguments would be able to process them (received as plain BLOCK! vs. a quoted BLOCK!)...and we'd make APPEND and friends take their arguments as meta.
Isotopic blocks don't exist today (though they'd be trivial to add, they're just BLOCK! with a quoting level of -1).
It would seem to have virtue over ONLY and is a better word.
So my perspective was at one time informed from having tried a lot of approaches...and I've gone through so many times of re-rigging the entire code corpus it's sort of maddening.
When I did, I was surprised to find that splicing as default intent was a rhythm I preferred. It's been a while since I've done it...and I probably should have taken better notes on exact cases that made me feel that way.
(UPDATE: going through with the new proposal showed me that the cases that feel the biggest bummer to change are with literal blocks, e.g. append file-list [%foo.txt %bar.txt]
. There's a bit of a negative feeling when having to change that to APPEND/SPLICE. I think this negativity is less when it's not a refinement, so append file-list splice [%foo.txt %bar.txt]
... and maybe we could come up with a symbol for this. But having looked at this so long I think it's just right... and if you want to make that cleaner you can make a gathering construct local to the function called ADD (or whatever) that specializes it all out to just add [%foo.txt %bar.txt])
Maybe my feelings are outdated and I should reevaluate it in light of these isotopic blocks. I think so. It's a systemic solution that would apply across the board (e.g. in COMPOSE).
spread: func [value [any-block! any-group! any-path! any-tuple!]] [
return unmeta quasi as block! value ; isotopic, e.g. "quoting level -1"
]
Maybe things need to be controlled by refinements... like which things you want to splice or not. Maybe it's an arity-2 function... spread block! value, spread [block! any-path!] value. There could be variations...build your own...use symbols. Maybe skippable @ parameters... like spread value vs. spread @block! value or spread @[block! any-path!] value
(Point is it's something you could write in usermode, and design the behaviors creatively... functions that sometimes return a block isotope, and sometimes don't.)
I'm warming up to the idea by realizing that we basically are already having to make APPEND & friends act like they take value as ^META anyway...so...might as well make it official.
Either way, no use rushing at this point!
Better to get it right.