Historically, a plain GROUP! in PARSE runs the conventional evaluator. But it discards its result and doesn't put it into the stream of parse instructions.
That means you can't do things like this:
parse "aaa" [some (either condition ["a"] ["b"])]
Because the "discarding" behavior of GROUP!s in PARSE is so pervasive, it seemed hard to challenge. So Ren-C had adopted the GET-GROUP! as :(...) to be non-discarding form, which you could use to splice arbitrary arguments or instructions into the PARSE stream.
But to @rgchris's taste, the colons are ugly. I can see it that way.
We could turn it the other way, and say you have to explicitly throw results away...otherwise they are kept.
parse "aaa" [some ["a" elide (print "found an A")]]
A failure to put the ELIDE there would mean you'd be trying to splice the PRINT result (a ~none~ isotope) into the instruction stream, which we'd imagine is an error.
The choice to elide could come from inside the group as well:
parse "aaa" [some ["a" (elide print "found an A")]]
Or use something that returned a ~void~ isotope...since that's ignored by the parse stream. This is the mechanism by which branching constructs can be used to good effect:
parse "aaa" [some ["a" (if false ["b"])]]
It Gets Rid of the Colons, but Does It Suck To Use?
I'm not so much concerned about backwards compatibility, as I am about two issues:
Is it actually, measurably, knowably better.
Will the machinery bend to allow emulation of the Rebol2 semantics.
I'm interested in (2) because I kind of insist on being able to implement Redbol. So I'd like there to be some kind of hook to choose. Ideally it would be the kind of hook that would have allowed a motivated individual to add something like the behavior of COLLECT and KEEP as it acts now to PARSE.
2022 UPDATE: UPARSE offers all this, and more! How far things have come since October 2020!