Hi Christian,

Thanks for the clarifications. This helped a lot and makes me feel very confident about this
 implementation. I think this is a very strong proposal.

A few additional things I thought about while taking a closer look:
- You mention "global" and "static" as examples of how we do things today. They are actually
 not good examples because the binding by reference which they do has been a real pain over 
the years. This is why we introduced the $GLOBALS[] array so that you could also assign by r
eference ($GLOBALS["foo"] =& $var). Now that I think of this example I'd actually prefer to 
see $LEXICALS[] or something similar to access variables then go with the broken global/stat
ic behavior. This will bite us and people will complain... In general, I always recommend to
 people to keep away from "global" and go with "$GLOBALS[]".
- Minor implementation suggestion: I am not sure we need those flags for closures and have t
hose if() statements before function calls. We took the same approach with other obfuscated 
functions/methods/variables. If the developer *really* wants to cheat the engine and assembl
e an obfuscated name then he can. It's like doing the following in C: ((fun(*)()) 0x454544)(
). I say, be my guest. It just simplifies implementation a bit. No biggy but consistent with
 the rest of PHP.
- Please check eval(). I assume it will bind to global scope but let's just make sure what h
appens esp. when it's called from within a method...
- In PHP 5, object storage is resources done right. I don't think we should be using the res
ource infrastructure for this implementation and would prefer to use the object one. It's be
tter. I suggest to take a look at it.

Will also look into byte code cache implementation issues incl. performance pieces but it lo
oks like there shouldn't be any show stoppers here but I want to verify.

Thanks again for your hard work!

Andi