The quoting question has always had an issue of "do you keep the identity of the thing in the array or the quoted thing":
>> data: [[a]]
>> rule: ['[a]]
>> result: parse data rule
== [a]
>> append result 'b
;... did you just change DATA, or RULE.1?
;... hopefully not neither (it should not synthesize a COPY!)
Today's answer to this question is that you get the rule, not what it matched:
>> same? result unquote rule.1
== \~okay~\ ; antiform (keyword!)
Not only that, you get a CONST version of the rule, to help avoid misunderstandings/accidents:
>> append result 'b
** PANIC: CONST or iterative value (see MUTABLE): []
I think it's probably right to give you the rule, because that's what it has to do in the cases of a string or binary match (of the molded form).
>> parse "[a]" ['[a]]
== [a] ; no block in the input data, so it *had* to come from the rule
So it feels consistent to me that you get the rule in the list case too.
But How Do You Ask For What's In The List?
Getting what's in the list is what happens when you're using a non-literal match:
>> parse [[a]] [block!]
== [a]
But since QUOTED! is out of the running, how to do this matching literally?
We could say this is what standalone @ does:
>> data: [[a]]
>> result: parse data [@ [a]]
== [a]
>> append result 'b
== [a b]
>> data
== [a b]
I had the idea of making @ mean "match any item here", but ONE is feeling better for that (and I feel like maybe * has enough benefits to choose it as the alternate form instead).
Then you have questions about applying the binding or passing as-is. Maybe the distinction of $var vs @var is "bind vs don't", and that applies to $ and @ as standalone operators here too?
Anyway, I Think QUOTED! Is Sorted Out
The idea of returning the rule, and returning it CONST, seems like the right answer.