Overall I think CONST and MUTABLE have been a huge success...catching potential problems, while still letting those who really want to force mutability get their wish.
But just now in writing tests for what I suggested about Virtual Binds being CONST by default, I was confronted again by a behavior I call out above. When you quote things, the quoting makes them subvert the const wave...it's true for loops, and it's true for virtual binds too:
>> loop 2 [data: [], append data 10, append data 20, print mold data]
** Error: ...data is `const` because it is in the "wave" of the loop body
>> loop 2 [data: '(), append data 10, append data 20, print mold data]
(10 20)
(10 20 10 20)
On the other hand, you would be protected if you'd not used quoting, which looks more palatable these days using THE:
>> loop 2 [data: the (), append data 10, append data 20, print mold data]
** Error: ...data is `const` because it is in the "wave" of the loop body
That may seem unfortunate. But if quoting couldn't accomplish this, then every API that wanted to splice mutable values would have to use MUTABLE.
REBVAL *block = rebValue("[1 2 3]");
rebElide("loop 2 [append mutable", block, "10]");
...and if you had to do that for every block, it would undermine any cases where the block itself was actually const.
I think it's now inevitable that an evaluated QUOTED! will have the same semantics as if you had fetched the value out of a word, not the same semantics as if you'd gotten it as a parameter to a function like THE. So a good guideline is that you should either use var: copy '(...) or var: the (...) when declaring GROUP!s as variables. Because var: '(...) won't offer protections for constness to inform you about whether you likely intended a COPY.
This is a fuzzy medium, and so the checks aren't going to be foolproof. 