So it occurs to me that this could be of benefit when dealing with the sticky SET-WORD! binding problem. When you're enumerating an OBJECT!, you could have to request for the keys to be bound to the object:
for-each [$key val] obj [...] ; key is bound to object
for-each [key val] obj [...] ; key is unbound
So, let's imagine you tried to copy an object via COLLECT of some code with a FOR-EACH, and you wrote:
make object! collect [
for-each [key ^val] obj [
keep spread compose [^(key): (lift ^val)]
]
]
(That's a fairly general solution, though it doesn't cover things like when an object's fields are "truly unset"... and if a field has type checking/etc. you'd have to use a different mechanic.)
ANYWAY... if that key had a binding, then the SET-WORD you got from (key): would have a binding. That's an easy mistake to make (and good to error if you make it).
I think defaulting to not having a binding, and having you say [$key ^val] to get a binding, looks like a good idea.
But I'm not sure how this generalizes. I was hoping that things like FOR-EACH were generalized on making calls to a generator. My thinking about how object enumeration worked would be that it would return a PACK!, such that if you just said for-each 'key it knew to give you just the first element of the ~[key value]~ pack, instead of giving you the value as the next key in the loop. That seemed to work... but now we have to have some kind of channel to communicate if we want the generator to bind things, and that applies to every potential element of a pack... (?) 
Passing the variables to the generator doesn't feel right, at best it should either offer a :BIND or not. Maybe $[key ^val] is what you'd have to use, to say "I want the answer bound" and it understands that only applies to the keys. That's not very good.
I'll have to think about it. Anyway, it's desirable to be able to ask the key to be bound to the object or not.