I will point out that UPARSE builds on basics in ways that e.g. Red PARSE does not. Consider:
red>> find "abcd" ""
== none
red>> parse "abcd" ["" "abcd"]
== true
Is there a "" at the beginning of "abcd" or is there not? They have different answers because they don't run through a common code path.
UPARSE actually builds on FIND, and for this reason has a consistent answer:
>> find "abcd" ""
; first in pack of length 2
== "abcd"
>> parse "abcd" ["" "abcd"]
== "abcd"
Note also that Ren-C FIND tells you the tail position of finds if you want it (that's why it's a pack).
>> [pos tail]: find "abcd" "bc"
== "bcd"
>> tail
== d
So things are a step forward in that respect.
But I'm certainly willing to hear about ways to improve UPARSE's design. Though the biggest question I've had since the beginning is whether there's any way to do streaming parse...and if we should be operating on a model where the parsers "put back" input they look at but don't consume:
Parsing Giant Streams Without Consuming Tons of Memory: How?