We only support Clangs that implement nullptr as an extension in C++03 mode, and we don't support GCC in C++03 mode. Hence, we can technically drop our emulation for std::nullptr_t in C++03 mode. Doing that is technically an ABI break since it changes the mangling for std::nullptr_t. However:
(1) The only affected users are those compiling in C++03 mode that have std::nullptr_t as part of their ABI, which should be reasonably rare.
(2) Those users already have a lingering problem in that their code will be incompatible in C++03 and C++11 modes because of that very ABI break. Hence, the only users that could really be inconvenienced about this change is those that planned on compiling in C++03 mode forever - for other users, we're just breaking them now instead of letting them break themselves later on when they try to upgrade to C++11.
(3) The ABI break will cause a linker error since the mangling changed, and will not result in an obscure runtime error.
Concretely, the motivation for making this change is to make our own ABI consistent in C++03 and C++11 modes and to remove complexity around the definition of nullptr.
Furthermore, we could investigate making nullptr a keyword in C++03 mode as a Clang extension -- I don't think that would break anyone, since libc++ already defines nullptr as a macro to something else. Only users that do not use libc++ and compile in C++03 mode could potentially be broken by that.