I can see why ANY makes more sense...to mean "any number of matches" (including 0). But a disadvantage is that it looks a lot like the common ANY construct in regular code... which kind of has the opposite meaning (non-PARSE ANY means "at least one of the following things, go with the first one that's truthy, else return null").
Because we're sort of dealing in a gray area of learned behavior here, I wonder if the benefit of going with MANY to make parse rules look different is enough to prefer it.
Also, they use EOF instead of END. END is literate, but one often wants to call variables things like "begin" or "end", or "start" and "end".
This makes me wonder if perhaps we should be a bit more creative in the use of datatypes. If you want to match a WORD! in a dialect, you have to use a tick mark. What if you had to use a tick mark to match TAG!s, and then an ordinary TAG! could have meaning as a rule...such as
parse "aaa" [data: copy to <end>] parse "<div>stuff</div>" [x: between '<div> '</div>]
Anyway, that could open up a whole new category of combinators... tag combinators. Maybe
<here> is another example, or perhaps
<input> if you want to pass the original input position through to a function.
A unifying concept here could be that you'd use it for properties that you don't want to have collide with the names of variables. Consider for example if PARSE tracks the line number, you might want to say something like
line: <line> in the middle of a rule.
If you want to match tags by their stringness, it's not like it's all that hard to just say
"<div>" in the first place. But quoting is even briefer. Remember that being inert in typical evaluation is not enough in PARSE to mean it's not a rule... INTEGER!, BLOCK!, BLANK! (previously NONE!) and now LOGIC! all have to be quoted to mean their actual literal thing. And quotes are needed on things like WORD!, GROUP!, GET-WORD!, SET-WORD!...and much more.
So is it worth it to get another dialect part, by making you have to quote your tags if you want them to match literally? I kind of feel like it would be. Of course, the concept with UPARSE is that people could disagree and make entirely different answers...
(Note: a downside here is that since TAG!s are strings and not symbols, the comparison costs could be (slightly) higher. However, I've been thinking that to speed up string comparisons they might cache a symbol as part of the comparison process...and clear the symbol cache on each mutation. Then comparisons of strings to symbols could become very fast...so long as the string isn't changing. Wouldn't help if it were looked up in a map, but the optimized native version could do a fast check before hitting the map.)