Patch attached ... while this has the desired outcome, I've not tested and don't know if it introduces inconsistencies elsewhere. 

I would assume there is some non-obvious reason this wasn't done in the first place ?

<?php

$bin = "0b100";
$hex = "0x04";

var_dump((int) $bin, (int) $hex);
var_dump((double) $bin, (double) $hex);

var_dump(is_numeric($bin));
var_dump(is_numeric($hex));

var_dump(intval($bin), intval($hex));
var_dump(floatval($bin), floatval($hex));

Yields:

int(4)
int(4)
float(4)
float(4)
bool(true)
bool(true)
int(4)
int(4)
float(4)
float(4)

All Zend and ext/standard/string tests passing ...

Dmitry, assigning to you to get some attention, this appears quite important to me. I'm not able to say if the patch has adverse performance impact or introduces some strangeness you purposely left out. 

It looks good to me ?

The one particular thing I'd be worried about is someone using is_numeric() to check that a string is a number (eg, form input) and then inserting that into a SQL query: if a user entered 0b100 that now looks numeric but MySQL, for one, doesn't support it and the query would fail. (Meanwhile hex looks numeric already but MySQL supports it.)
The other methods - int cast, *val() - are fine because they return a new value rather than return just information (numeric-ness) about the value.

However fixing all but is_numeric() would be even more horribly inconsistent...

Consensus is that hex support in is_numeric_string should be removed (see e.g. http://markmail.org/message/ax2drcb6dolr5agl). Doing it the other way around would be a major PITA, as we'd have to support not only binary, but also octal and would have to add support for it in typecasts as well. (Try to explain to an end-user how 0123 and 123 are totally different things...)

But we can't remove this just now, will have to wait to next major.

Added this issue to RFC to track.
https://wiki.php.net/rfc/comparison_inconsistency

This was the non-obvious thing that didn't cross my mind:

(Try to explain to an end-user how 0123 and 123 are totally different things...)

It doesn't really make a lot of sense to me to support anything at compile time that cannot be supported at runtime, if the compiler understands something then so should the executor.

If we cannot support it then they should all be removed, maybe introducing utility functions to work with these forms, instead of trying to half bake it into the engine.

I'd prefer to just remove them if they cannot be supported sanely, there isn't really another good option.

I would agree to remove hex numbers support in is_numeric_string() (in PHP-5.6), but it really may break some code.

No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Re-Opened". Thank you.