In UPARSE, there's a MAP! of all the combinators. You can map fundamental datatypes to combinator functions, or you can map literal elements to combinator functions (as keywords like SOME or ACROSS are)... or you can map literal elements to something to substitute as a rule.
(e.g. you can map a literal element to a parse rule block!, and it will use that block as the implementation of whatever you mapped. You could map <_> to [opt some whitespace] if you wanted.)
But now FOO:BAR, FOO: and :(FOO) are all becoming CHAIN!
It's likely that foo:bar would be handled by the combinator mechanics themselves, to provide refinements to the combinator. So it wouldn't be dispatched to the "CHAIN! combinator".
But we've been handling foo: and :(foo) very differently. But they're both the same type: CHAIN!.
Problem is, there are no variadic combinators (yet?). So you either map the CHAIN! to a combinator that takes an argument or you don't. The foo: needs an argument, the :(foo) has been evaluating the group and splicing it as a rule to execute.
Cheap Solution of the Moment: Hack The Dispatch
The terrible but "let's keep things moving" answer is that if you have any sequence with a leading blank, it will try dispatching to :* or /* or .* ... e.g. those literal sequence patterns are what you put in the combinator table.
And if it has a trailing blank, you put *: or */ or *. and give those a combinator.
If both of those fall through, it goes to the plain CHAIN! or PATH! or TUPLE! combinator.
Shoddy...of course. How to do better?
Could A MAP!-Like Structure Optimize Pattern Match?
As a non-compiled language, we can't do much to optimize something like DESTRUCTURE if the moment we encounter it is the first time we've seen it.
We could have a data structure that is internally optimized to pattern matching. e.g. something like a MAP! but that has architecture inside of itself as a data structure that groups patterns that are close to each other together, and branches off at the appropriate points.
I don't know how to implement it, but I do know that if we turned the combinator map into a list of destructure rules that it tested one at a time in order, that that would be really slow... even if destructure were native.