Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php

set_error_handler() only installs one error handler. The mask doesn't mean "install this handler as the handler for this mask" but rather "install this handler as the one custom error handler but only call it for this mask".

The other bug is about how previous error handlers are saved in a stack and can be recalled later but that the error mask is not treated the same way. A different issue; if you restore_error_handler()d after your code then the first handler (also $cb so you wouldn't notice the difference) would be restored but the mask would remain unchanged at E_WARNING.

Thanks Damian, 
I see what you mean, and it turned to even worse behaviour: in my scenario the handler I carefully defined for E_NOTICE errors will never be called. 

set_error_handler(function(){echo 1;}, E_NOTICE);
set_error_handler(function(){echo 2;}, E_WARNING);
echo $someUndefinedVar;

results with ugly "Notice:  Undefined variable: someUndefinedVar" instead of beautiful "1".

I respect that my expectation to fire my handlers are too high, and it is not a bug. Could we classify it as a feature request then? 
You see, having a returned value from set_error_handler() I have no information about what errors it was handling before, which make it useless. What realistically you can do with previous handler with current implementation?

There's actually a request for multiple error handlers already, though a bit old.
https://bugs.php.net/bug.php?id=54548

On the bright side it's not too hard to implement your own "add_error_handler"-type function using a class: a method to add an error handler to an internally-managed stack, and a method that is the real error handler that goes through the stack calling handlers with matching masks until one succeeds (and if none do returns false so PHP's default handler takes over).

That's it. We are implementing the stack using closures, and not sure what to do with callable response of the setter. A non-null result clearly states that some other lib set it's own handler and relays on iit.We feel it is not fare to throw it away,  yet we have no idea how to use it. 

Thanks for the link tho. It is the feature we really need.