I hope they don't, at the very least we can afford to choose a new keyword. Even if auto was infrequently used, it's no good to silently change the meaning of existing valid programs.
Would it change the meaning of existing valid programs? C's "type inference" algorithm is to assume that everything is an int by default. So
auto x = 7;
is equivalent to
auto int x = 7;
which is equivalent to
int x = 7;
(since "auto" is the default storage class). If the C standard folks do things right, then the only change will be to allow some previously invalid code like the following:
auto str = "foo";
Such code will compile on a C compiler (hopefully with a warning!) but won't have a defined behavior. I guess a more problematic case would be
auto x = 9999999999999L;
Where the value will be truncated in C but will be inferred as a long in C++ (assuming typical sizes for int and long int). Again, though, I am not sure if truncation of signed constants has a defined behavior in the standard.
auto pi = 3.14;
double result = 2 * pi;
printf("the circumference of the unit circle is %g\n", result);
When interpreted as C89 program, this computes the value 6. Compiled with a C++ compiler it computes 6.28. This is exactly due to that both languages have an auto keyword, but they mean different things.
This situation is perhaps not so likely to occur in real usage, but I think it could and should have been avoided.
Naturally at this point one could ask why not just use C++ instead, well that is what happens when a language group is so firmly against moving upwards, but still wants the features on their language.
Naturally missing from the list are any kind of improvements to string or arrays alternatives, as usual.