Chris,
There are a lot of messages for me to catch up on from today, but I am heading home from work, and your most recent one is the easiest to address quickly.
I want to start out by saying I agree with many of the objections and concerns raised here, and there were some I had not thought about. This is why I put the proposal out, to learn more and perhaps make a stronger proposal (I like the idea raised last night of denoting these variables with a keyword to denote they are special and should be treated as such).
Yanhao, I do not think you are doing this proposal any good. I appreciate you trying to go to bat for it, but there are many good concerns here that would be good to hear out and address rather than trying to dismiss them.
To your last message Chris, I just wanted to point out one way I envision this may be used used (Although it is still a bit of a toy). In my longer examples.py file I have a history variable that tracks all the values that were bound to the name (using __setself__) in a history list. __getself__ would then always return the most recently set value when loaded. I introduced a "built in" called getcloaked what would allow fetching the actual cloaking variable such that it could be used. In this case that would be something like getcloaked('var').rollback_history(2) to move back to a previous assignment. This could potentially be used in say a debugger, or try except or the like. As you say this would only be good from within a single scope, unless the return statement of the function was: return getcloaked('var') (or conversely a function was called like foo(getcloaked('var") to pass it into scope).
I do think that this proposal needs work (or possibly thrown out all together if it could not be refined), and all the ideas and questions were exactly what I was hoping for, as there is more that others will be able to see than I am alone.