I should mention that dialect-wise, if you're doing quasiform annotations to mean something for variable references (for example), and you get to the point where you need tuples, then instead of ~var~ you say ~(obj.field)~.
For the sake of simpler processing in your dialect, you might just always mandate the group, e.g. ~(var)~ . But that's up to you based on what look you are going for and the other tradeoffs in your dialect.
I prefer this "reified escaping" to "lexical escaping"
Lexical escaping would be something like this:
>> tuple: to tuple! [~ a]
== ~.a
>> quasituple: quasi tuple
== ~\~.a\~ ; or some other arbitrary escaped-rendering method in the system
>> unquasi quasituple
== ~.a
Rethinking that with reified escaping:
>> tuple: to tuple! [~ a]
== ~.a
>> to group! reduce [tuple] ; a.k.a. ENVELOP/GROUP a.k.a. ENGROUP
== (~.a)
>> quasigroup: quasi engroup tuple
== ~(~.a)~
>> first unquasi quasigroup
== ~.a
This resembles other places that I've taken this bias.
It represents a shift in my thinking from a decade ago when I advocated for lexical escaping: I thought the system needed to do things like permit words with spaces:
r3-alpha>> word: to word! "word with spaces"
== #[word! "word with spaces"]
r3-alpha>> type? word
== #[datatype! word!]
r3-alpha>> setword: to set-word! word
== #[set-word! "word with spaces"]
r3-alpha>> make object! compose reduce [setword 10]
== ... oh what a tangled web we weave ...
With hindsight and a greater vocabulary of containers, I no longer believe this is a good idea. (Datatypes are another area that have undergone the shift, with word! defined as &[word] being a TYPE-BLOCK!)
In the grand "freedom to vs. freedom from" balance of things, it's better to err on the side of solidity. The overall systemic Quality-with-a-capital-Q becomes higher by tightening the fundamental bricks...and using reified escaping.
>> type of '[spaced words in block]:
== &[set-block] ; ...note: will be &[chain]