if( is_numeric( chr(0)) && is_numeric(chr(1)) )  # <-- changed to &&
    echo "is_numeric is great!";
 else
    echo "is_numeric might be a little buggy";

I also tested chr(0) and chr(1) with is_boolean and of course the function says it is not.
I think is_numeric and is_boolean should be revised to include 0, 1, chr(0) and chr(1) as valid numeric and valid booleans.

No, definitely not. chr(0) is a NUL which is distinct from the number 0 and 
chr(1) is a SOH character which has absolutely nothing to do with a number.

Do you know the binary numeric system ?
Chr(0) is the octet 00000000 which value is 0, so it's NOT different from zero.
Chr(1) is the octet 00000001 which value is 1, NOT different from the numeric 1.

These two chars should ALSO be recognized as boolean in the "is_bool" function too. Everybody that program in C knows that 0 and 1 are the real booleans inside the engine.

If you are so sure, take the chance, and tell the MySQL team that they are wrong, because they are storing chr(0) and chr(1) for bit(1) values. 
Bit is defined as numeric data type in MySQL

Yes, binary is 0's and 1's at the low level. So is octal, decimal and hexadecimal 
or anything else you represent digitally. What matters here is the character 
representation of these numbers. The character representation of binary (as of 
PHP 5.4) is 0b0101 (for example). Just like 05 is octal, 5 is decimal and 0x05 is 
hexadecimal. All of these make is_numeric() return true.

@dosergio

Chr is a PHP function that returns a string with the specified character code. Try this:

var_dump(chr(0));

It says:

string(1) " "

It's a string, and not a string containing a human-readable number, so is_numeric returns false as it says it will do in the documentation.

>numeric in the binary context

Everything is numeric in the "binary context". If is_numeric returned true for that reason, then it should be hard-wired to return true always, because you cannot possibly pass it an argument which is not made of bits.

>Tell the MySQL team that they are wrong, because they are storing chr(0) and chr(1) for bit(1) values.

I won't say that they're wrong, but they're definitely different to all other databases in this way. Read: http://www.xaprb.com/blog/2006/04/11/bit-values-in-mysql/

For some reason, new versions of MySQL return BIT columns to clients as strings instead of integers. To avoid the problems this causes, you could do one of the following:
(a) use an integer column instead (e.g., TINYINT(1) instead of a BIT(1))
(b) put +0 in the SQL expression, which forces the bit value to be returned as a number
(c) use the PHP ord() function to convert the character into its character code.

In any case, it's not a PHP bug.

Thank you. You made me see that the problem is really with MySQL, not PHP.
I thought PHP x MySQL were totally compatible, but as we see, the bit data type is only bit for MySql, PHP sees it as non numeric string.
I imagined php could validate only chr(0) and chr(1) as valid numeric string exactly to make php even more glued with MySQL.
You are right about the binary context, and I suggested to have a special treatment only if the char was chr(0) and chr(1) not any others out of 48~57.