So I'm really a fan of it when languages let you do things like introduce variables in loop conditions that are only visible in the body.
C99 actually lets you do this with for loops (not others, though):
for (int x = 0; x < 10; ++x) {
printf("value is %d\n", x); // this is legal
}
So it would be nice if you could do something similar in Ren-C:
while [let item: try take block] [
print [item]
]
You can't do that today... the LET is only visible until the end of the condition scope. So you have to write:
let item
while [item: try take block] [
print [item]
]
That's not as nice. 
What Would It Take To Implement?
So it would be kind of tricky, in that the body block can be bound somewhere entirely radically different than the condition. It could be using a whole different concept of LIB.
You don't want to overshadow the binding of the body with all of the context of the condition. You'd only want just the diff... any new definitions that appeared in the context chain while it was running. But only those.
Arguably there are cases where people would not want to inherit the diff. Creative uses of WHILE which put a lot of code in the condition might want to make variables that don't leak out. But you could deal with that intent using a GROUP!
let item: <outside>
while [(let item: try take block)] [
print [item]
]
Bizarro idea might be that GROUP!s themselves as conditions (or bodies) indicate you want transparency of diffed variables beyond the loop:
while $(let item: try take block) [
print [item]
]
assert [item = null] ; iteration exhausted, item still visible
That's a pretty wild idea... but it doesn't really have any precedent with what GROUP!s mean generally (e.g. (let x: 10) more generally won't leak the X out of the group, and it shouldn't.
Generic Mechanism Would Need A Design
I could hack this behavior into WHILE. But for all these things, I think it should be possible to do in your own constructs.
It means EVAL needs to have some kind of context return result that gives you a partial environment chain of what got added.
This could basically reuse an existing chain, by being a counter of how much of the chain was applicable if you followed the link. This could go in the cell, and then be proxied into a stub if you actually used it.
It's desirable to do, so I'll put it on the infite list... 