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, having the colons may be worse than rethinking the rule...to instead one in which you have to explicitly throw away the result. So we'd presume PARSE would have an ELIDE keyword.
parse "aaa" [some ["a" elide (print "found an A")]]
In a new way of working...a failure to put the ELIDE there would mean you'd be trying to splice a #[void] into the instruction stream, which we'd imagine is an error. (You'd need a quoted void to match an actual void value).
The choice to elide can come from inside the group as well:
parse "aaa" [some ["a" (elide print "found an A")]]
Or use something that returned NULL...since a NULL splice is 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"])]]
Note: In the early days of expression barriers, I mused this kind of approach could be done with an idiom that would look like what some languages call "banana clips":
parse "aaa" [some ["a" (| print "found an A" |)]]
Under that proposal you wouldn't need the barrier on both ends, but it might help. Today's expression barriers only block evaluations and don't overwrite evaluations, though. But it's a bit interesting, and shows the proposal is not fully "new"
A Significant Change, But... Is It More Intuitive, and Better?
Using GROUP!s to splice material into parse rules...or to act as arguments to rules...is a desirable feature.
If you imagine people being introduced to GROUP! as not discarding, if it would just seem to make more sense to work with them generically. PARSE rules would be more creative with less repetition from the get-go.
And with ELIDE functioning in the evaluator, they could build on that knowledge in PARSE to know they have a way to wedge value-generating code into a place where they need that value to disappear.
The other worldview...that GET-GROUP! is a non-discarding form of GROUP!...and plain GROUP! discards the value...doesn't have a basis in anything.
Note: I'm thinking that @ groups will continue to have their "as-is" meaning, which is to say that if you keep @[some integer!] then you are asking to keep the actual two words
some integer!, while keep [some integer!] would act as a rule that would match the input for some number of integers. Similarly, keep @(reverse [integer! some]) would keep the two words some integer! as well, while keep (reverse [integer! some]) would be a request to match input.
Concerns To Address
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 think at first I was reluctant to think it could be better, based on thinking "there's a lot of points in parse rules that trigger code, and having to put ELIDE on all of them sounds burdensome".
But the game has changed in some ways. For instance, as invisibility is on the rise for you don't have to worry about injecting (-- pos) to dump a parse position variable, because the same invisibility that works inside something like CASE or ALL works here.
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 for this. 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. I'm still trying to work that out.
I do feel like the idea deserves a shot, because when I look at it now it seems like how PARSE probably should have been done to start with. And we want to show best practices to people trying to implement dialects--and build infrastructure to help with those best practices--which are now informed by things like NULL-ness and invisibility...