Plus, A New Reason To Keep The Meaning Free...
If we can truly disconnect what parentheses mean in this context, we can also liberate brackets and fences, into something I have referred to as Dialected Function Calls.
This started from the idea of rewriting things like:
fail:blame ["This failure will implicate VAR at callsite"] $var
Into:
fail:$var ["This failure will implicate VAR at callsite"]
Basically, handing control over to the function to say "here's the CHAIN! that invoked you, why don't you interpret it how you want".
So if we assume CHAIN! doesn't presume the meaning of GROUP!... or BLOCK!... or FENCE!... or INTEGER! or $WORD! or anything... we get some nice expressivity:
For instance, what if COMPOSE could take the pattern you use to compose with?
>> compose:{} "some stuff {1 + 2}, (not composed)"
== "some stuff 3, (not composed)"
>> compose:[] "some stuff [1 + 2], (not composed)"
== "some stuff 3, (not composed)"
>> compose:((*)) "some stuff ((* 1 + 2)) (not composed) ((nor this))"
== "some stuff 3, (not composed) ((nor this))"
That example alone exceeds the usefulness of any cases I can think of where GROUP! evaluations were used to pick refinements.
Design TBD... 
I'm not sure exactly what API you'd use to specify that you want access to the CHAIN! to interpret yourself, or how you would delegate the chain processing to refinement processing so you didn't have to rewrite that bit (maybe WORD! is always interpreted as refinement, and your dialect can only heed things that aren't words?). And I don't know how it would work with APPLY.
But, it's something that seems fairly exciting to me if it could be pulled off... and I think I've talked through some of my binding concerns enough to where that wouldn't be the problem I thought it might.
I still think CHAIN!s that aren't function calls should treat GROUP! as they do today:
>> foo: null
== ~null~ ; anti
>> var: $foo
== foo
>> (var): 1020
== 1020
>> foo
== 1020
And probably a GROUP!-headed CHAIN! should still evaluate the first item as a GROUP! as it does today:
>> fn: append/
>> (fn/):dup [a b c] [d e] 2
== [a b c [d e] [d e]]
But the idea that there's a universe of dialecting available to the function in the CHAIN! has so much advantage notationally. It may be able to sort out the question of wanting to inject parameters at the beginning instead of the end when using refinements. (?)