LSB happens with the static keyword, not class names. Classes always resolve according to the namespace of the code being executed (or by use statements), not some kind of contextual namespace dependent on where the code is being executed.

echo static::$Value;

Don't forget that trying to access an undefined static property will fatal.

Sorry to say, but you did not understand the example provided. Please go through it again and find that it has nothing to do with late static binding.

Your suggestion is invalid. A static::$Value is not defined, as we want the $Value property of a different class: \Alpha\Helper. So we access it as Helper::$Value.

And here comes the problem. When later both classes are inherited / copied to \Beta namespace, the Helper::$Value readout still accesses \Alpha\Helper::$Values, but it should be using \Beta\Helper::$Value.

That may be but it's still not a bug. There is no such feature like what you're describing; the closest is LSB which is why I brought it up.

Your options include
a) Beta\Base redefining Write() to use the Helper class that it wants to use.
b) (Ab)using get_called_class() to extract the called namespace, test that the corresponding Helper class exists, and use its $Value.
c) Dependency injection, which sounds like the best solution to whatever you're trying to do.

The example shows a clear breach in namespace/inheritance logic - this qualifies as bug.

As you explain a mere c&p of the method to the new class would resolve the issue. I remeber reading nearly the same tips here, when LSB wasn't there and people claimed __CLASS__ was sufficient for everything and for everything else just c&p. I personally stay away from hackish tricks, the important namespace functionality should be consistent. So my suggestion is focusing on the problem not the alternatives.

There is no inheritance in the first place. "Helper::$Value" does not work as a relative path but is merely shorthand for writing "\Alpha\Helper::$Value", and was resolved as such at compile-time.

The feature you're trying to report a bug for *does not exist*.

Sorry, but you are wrong again. Please double check your own PHP documentation, where it says:

"Inside namespace (say A\B), calls to **unqualified** or qualified class names (not fully qualified class names) are resolved at **run-time**. ".

This describes exactly what I am expecting.

Hmm. Compile-time for imports and HHVM seems to do it at compile-time regardless <http://3v4l.org/Ec0jL/bytecode#tabs>. I guess I assumed it was compile-time for everything.

Regardless, the class name still isn't resolved that way. Did you see the next line? "It looks for a class from the current namespace: A\B\C."
- It had just said that A\B was where the "call" was
- There is no mention of any other code anywhere else - including code calling the code being executed

Now, can we call this resolved? I'm sorry about the mix-up but it simply does not work the way you thought it did. And frankly I'm glad it doesn't because such a scheme would be very confusing and awkward.

As written before this is a breach. The documentation is clear and consistent: Resolution is done at runtime, and -regarding your quote- respects the current namespace context, so in my example at runtime the instance is in \Beta namespace and this namespace and it's class should be used. That is the only logical and deterministic way to interpret the call to Helper::$Value. Other languages follow this priciple.

So IMHO this remains a serious flaw, because PHP does not behave like expected and documented. You may call it a missing feature, though, that does not change the facts I pointed out.

https://gist.github.com/requinix/c3a576a5a8953d26da02

I've said all I can on this and there is no point trying to continue this debate. If I still haven't hit upon the right combination of words and explained to you why you're mistaken and why there is no bug then I doubt I ever could and you need to find somebody else willing to try.
http://php.net/support.php