I've taken my time to mull over this question, and not assume too much. I wanted to look at all the angles.
Having looked at those angles, I've reached a conclusion (which I suspected all along...)
IT WOULD BE A PHENOMENALLY INSANE WASTE OF AN OPPORTUNITY TO MAKE FENCE! (UNCONDITIONALLY) INERT IN THE EVALUATOR.
If you want an inert FENCE!, you can make one.
>> '{a b c}
== {a b c} ; unbound
>> ${a b c}
== {a b c} ; bound
>> @{a b c}
== @{a b c} ; bound
>> ^{a b c}
== ... ; I have no clue, yet
It's a golden opportunity to give people a surprising artifact, that does something "familiar" but is much more than meets the eye...
>> z: <outside>
>> obj: {x: 10, print "Hello" print "World", y: null, z: z}
Hello
World
== #[...object...]
>> obj.x
== 10
>> obj.y
== 20
>> obj.z
== <outside>
>> for-each [key val] obj [probe key probe val]
x
10
y
~null~ ; anti
z
<outside>
You've transitioned from a FENCE! ... which is a list structure that can only hold reified elements... to a key/value structure whose slots can hold stable antiforms.
Besides just plain assignments, you're allowed to run code. But the default construction should not assume WORD! references resolve inside the object as its being generated. There should be a way to get at those internal references if you need them, but I'm kind of opposed to defining any sort of THIS or SELF word in an evaluator primitive.