This is expected, but currently undocumented[1] and maybe
undesirable behavior. I don't think we can change that in a minor
version.

Related to bug #50892.

[1]
Some stupid broke the documentation in
<http://svn.php.net/viewvc?view=revision&revision=337719>
Fixed with <http://svn.php.net/viewvc?view=revision&revision=342692>

This is a consequence not of visibility, but of "duck typing". There is no difference in PHP between "redeclaration" or "overriding" and simply adding a new member - all lookups are dynamic at runtime.

It may seem odd at first that a parent class can access protected members of a child class at all, but consider this pattern:

class A {
    public function something() {
        // important logic
        $this->onSomethingHook($someEventData);
        // more important logic
    }
    protected function onSomethingHook($someEventData) {
        // No logic; extension point provided for sub-classes to add custom behaviour
    }
}
class B extends A {
    protected function onSomethingHook($someEventData) {
        // Custom logic here, which will be called from class A
   }
}

At a glance, you might say that A::something() is calling B::onSomethingHook(), but in fact the run-time behaviour would be identical if we declared A::onSomethingHook as abstract, or didn't declare it at all - as far as PHP is concerned, the lookup is against whatever $this resolves to at run-time.

If we required a declaration of onSomethingHook in A (or its ancestors), would we also require it with a public member? If not, why not?

class A {
    public function something() {
        $this->onSomethingHook($someEventData);
    }
}
class B extends A {
    public function onSomethingHook($someEventData) {
        // ...
   }
}