See T7339. A specific, chaotic locale behavior is that (string)1.23 is 1,23 in some locales. This can create issues when PHP code interacts with essentially any other system. For example:

$ cat ltest.php 
<?php

setlocale(LC_NUMERIC, 'de_DE');
echo http_build_query(array('n' => 1.23));
echo "\n";

$ php -f ltest.php 
n=1,23

So if you're building an API call this way, the call behavior will change if the locale changes.

It also affects the behavior of (double)(string)$x: the result of that expression depends on the current locale (for $x = 1.23, the result is 1.23 in locales that use decimal point as a separator, but the result is 1 in locales that use a comma).

In T7339, the particular point where this broke was INSERT INTO ... VALUES ('1,23'). In sensibly strict modes, MySQL raises a truncation warning about this. An argument can be made that the query layer's use of %ns ("nullable string") to build all the values could be improved, but this is still a bizarre behavior.

Display code already uses PhutilNumber and related format-aware code to format numbers correctly for display, so our choice of what (string) should do at runtime has (in theory) no impact on how users see numbers printed. In practice, since we provide a small set of locales and don't include rich number formatting locale data there may be some actual impact, but this can be remedied by updating locale definitions.

During other startup checks, we should guarantee that (string)1.23 is "1.23" and refuse to run if we can't satisfy this guarantee. T7339 has more nuanced variations on this and it isn't a complete description of desired locale behavior, but this should be a minimum property of the runtime environment we provide.