You can't do that for ",", because it will break the existing code.
For example, int x = 0; x = 1,2; is perfectly valid pre c++11 code. This will assign 1 to x. Now if you make "," as digit separator, it will assign 12 to x
I mentioned the possibility of a special prefix in my previous post. In other words, that parsing ambiguity goes away if the standards committee wanted to define a special prefix such as 'd', 'k', or '_' to inform the parser that the next comma is a "digit separator" instead of "comma operator" such as _1,000,000 . E.g. there's already intelligence about commas in the parser to disambiguate function calls with commas as in "repositionxyz(914,348,122)"
Or, they could have defined C++14 to simply invalidate your example syntax of "x=1,2". As an example, the "auto" keyword was made a "breaking change" such that "for (auto int i = 0;;)" no longer compiles.
The bottom line is that there are a myriad of ways to address (potential) parsing ambiguities when introducing new language features and syntax. (Whether or not a comma digit separator is worth the clumsier syntax of a special prefix or inflicting the pain of a breaking change is a separate concept.)
C++ doesn't have the friendliest grammar for addressing potential parsing ambiguities.
As an example, your proposed solutions
_1,000,000
k1,000,000
Both are already valid if variables or functions _1 or k1 are in scope, and evaluate to (octal) zero.
And I haven't checked, but it would guess that invalidating "x=1,2" in the parser would not be "simple". I cannot think of a reason, but it also might turn out to be more common then one would think due to macro expansions.
Or, they could have defined C++14 to simply invalidate your example syntax of "x=1,2". As an example, the "auto" keyword was made a "breaking change" such that "for (auto int i = 0;;)" no longer compiles.
The bottom line is that there are a myriad of ways to address (potential) parsing ambiguities when introducing new language features and syntax. (Whether or not a comma digit separator is worth the clumsier syntax of a special prefix or inflicting the pain of a breaking change is a separate concept.)