-1 because:

• This allows you to change constants (undef + def). Let me say that again: Change constants.
• This will likely cause unexpected behavior, because we evaluate many constant-based values only once. E.g. given a property which defaults to a constant public $foo = FOO; this constant will only be evaluated once. Changing its value with undef+def will not change the default value of $foo. Same applies to any other place using static scalars.
• ZEND_FETCH_CONSTANT currently uses our inline cache. This would no longer be possible and would thus slow down execution.
• This particular patch does not respect optional constant case sensitivity.

• doesn't seem that alien to me to change a constant, or to have #undef where there is #def
• doesn't work on class constants, globals constants only
• not sure about this one
• fixed

I have to agree with @nikic. Constants that change are... well, they're variables aren't they.

Once defined, I would expect a constant to remain defined, and unchanged. Absolutely entirely unexpected behaviour if a constant value is able to vary.

What is your actual use case for this? I can only think of scenarios that would be better solved with a different approach entirely.

doesn't work on class constants, globals constants only

Doesn't really matter. For context see zend_update_constant_ex, which we call on all static scalar values on first use. The function will resolve all constants (be they global or class) and compute the resulting value. So constant-based values (in static_scalar contexts) will only fetch the constant once on first use, but never again. So changes in the constant value will not be reflected there.

not sure about this one

See the first few CACHED_PTR usages in http://lxr.php.net/xref/PHP_TRUNK/Zend/zend_vm_def.h#3489. If you undef a constant, the zend_constant for it is destroyed, so you'll leave a dangling ptr in the inline cache.

ok, good enough reasons to drop it ...