The C++ standards committee is full of smart people that are fully aware of the amount of existing code and the consequences of introducing new keywords.

One of the aims of the committee is to keep as much existing code as possible working unchanged and that certainly plays a large role when deciding to add new keywords and how to name those keywords.

To my knowledge, when a new keyword is proposed, they perform an investigation over a number of large codebases to see how many conflicts that new keyword would create and if any of those conflicts would create a silent change in the behavior of the programs.

According to the proposal for adding nullptr, this spelling of the keyword resulted in the least amount of conflict with existing code:

• Programmers have often requested that the null pointer constant have a name, and nullptr appears to be the least likely of the alternative text spellings to conflict with identifiers in existing user programs. For example, a Google search for nullptr cpp returns a total of merely 150 hits, only one of which appears to use nullptr in a C++ program.

  • The alternative name NULL is not available. NULL is already the name of an implementation-defined macro in the C and C++ standards. If we defined NULL to be a keyword, it would still be replaced by macros lurking in older code. Also, there might be code “out there” that (unwisely) depended on NULL being 0. Finally, identifiers in all caps are conventionally assumed to be macros, testable by #ifdef, etc.
  • The alternative name null is impractical. It is nearly as bad as NULL in that null is also a commonly used in existing programs as an identifier name and (worse)
    as a macro name. For example, a Google search for null cpp returns about 180,000 hits, of which an estimated 3% or over 5,000 use null in C++ code as an identifier or as a macro. Another favorite, nil, is worse still.
  • Any other name we have thought of is longer or clashes more often.

Given this analysis, I don’t expect that that much adjustment needs to be done.
But otherwise, yes you are expected to update your codebase for the backwards-incompatible changes when moving to a new standard.

Introducing new language features and extensions, most of the time, require new language keywords or syntax changes. In addition, its essential to name these keywords for their intended purposes so as to help programmers memorize the new features. Fortunately, for that purpose, new language version/standards contain a list of code-breaking changes that you must consult before building the code with the new toolset.