This is interesting, I would think that the 5_4 functionality is more correct, 
because you're adding a null character as the thousands separator so the string is 
becoming: 
1\0328\0370\0011.72399998

Internally a null character terminates a C style string.  I would think the 
appropriate fix would be to limit the fourth parameter to displayable characters.

This probably changed as a result of a bugfix somewhere.

Ouch, this one's my fault, as it came in with the fix for request #53457 in 
revision 305937. (char) 0 was previously used to signal no separator, whereas 
now the lack of a separator actually signals no separator. Unfortunately, I 
didn't take into account that _php_math_number_format() returns a C string, and 
is hence null-terminated as a result.

The right fix here (which I'll work up and commit to trunk) is to change 
_php_math_number_format() and _php_math_number_format_ex() to return a zval, or 
at least have some other way of signalling the string length to the caller. 
Unfortunately, as this would break the ABI, about the best I can do for 5.4 is 
to emulate the old behaviour when the decimal point or thousands separator 
includes a null byte (which is to ignore it altogether: the 5.3 output doesn't 
actually include any nulls).

I don't think this is going to be considered serious enough to be included in 
5.4.0, given we're in code freeze, but I'll put together a patch and attach it 
here before committing it post-5.4.0.

3 months later, any news on the fix? This bug makes phpredis zadd useless:
https://github.com/nicolasff/phpredis/issues/113

"I don't think this is going to be considered serious enough"

You mean making PHP thinks 1000000 equals to 1 is not a serious bug? Do you know how many extensions/plugins uses number_format on number larger than 999?

What a joke.

I'm sorry, I don't have any time for PHP work for the forseeable future. 
Unassigning myself.

@clowns: Presumably you don't understand the concept of a code freeze.

see https://bugs.php.net/bug.php?id=62112