Another example that does not rely on optional-before-required arguments:

class A {
    public function m(array $a = null) {}
}
class B extends A {
    public function m(array $a = []) {}
}

By the way, I do not write = NULL, because I want the argument to be optional.  I write it, in order to be able to pass NULL as parameter.

Is this a bug? I don't see why it's a problem. Looking at the nikic's example, the method signature doesn't change, just the default value for the method.

In the original example, you're still requiring two variables, but the second one can no longer be null. I'm not sure what the expected behavior should be.

In all examples, you cannot pass NULL as first parameter to the derived m(), but you can bass NULL as first parameter to parent::m().  So the method signature changes, in terms of possible values that can be supplied.

There are bugs in 

 * zend_do_perform_type_hint_check (never verifies compatibility of zend_arg_info.allow_null) 
 * zend_get_function_declaration

The bugs in zend_get_function_declaration are because we make this assumption: 

    if (i >= required && !arg_info->is_variadic)

So do not generate the correct error message when you fix the type hint check.

It's 8am on Monday morning ... someone else should have a go ...

I wonder if we should go through RFC stage for that supposedly BC-breaking fix?

It's technically a BC break, but at the same time a big LSP violation bug.

If you relied on that, your code is technically anyway broken. (as passing null to a typehint of superclass should break,)

The fix was reverted