Really add a _SEQ opcode at construction time to implicit sequences!

[xparq]

Deferring it until match() is causing problems already (incl. blocking #5 etc.).
In any context, where a sequence rule must be identified, or operated on, this ambiguity/duality is a burden.

OTOH... This would cost things like _CAPTURE becoming more cumbersome, which can now be just tucked in front of any implicit sequence, and it just passes the remainder of a rule as-is to match() (which will imply a SEQ). Moving the conversion from run-time (match) to "static" grammar construction, CAPTURE itself -- and any other user-defined operators that create productions run-time!!!... -- would have to construct a proper SEQ out of their argument list (i.e. for prefix ops (which is: all...) it's "just the rest of the list"); just an iterator to a "next" in-place position of a const production would no longer work! A _SEQ opcode would have to be inserted!... :-/