Why not call nullptr NULL?

Stephan T. Lavavej (member of the C++ standard committee) explained that once in a talk (55:35):

While an implementation is allowed to #define NULL nullptr, it would break quite some uses like

int i = NULL;

and apparently there are plenty of those. So they could not force the change.

nullptr is of pointer type , while NULL has the tendency to be integer, and sometimes in overloaded functions, you need to be clear that you are using a pointer and not an integer - this is when nullptr comes in handy.

So to really answer your question, NULL and nullptr serve two different purposes and redefining one to another will probably break a lot of things in already existent code bases.

Beside that, check this from Bjarne Stroustrup's website:

Should I use NULL or 0?

In C++, the definition of NULL is 0, so there is only an aesthetic difference. I prefer to avoid macros, so I use 0. Another problem with NULL is that people sometimes mistakenly believe that it is different from 0 and/or not an integer. In pre-standard code, NULL was/is sometimes defined to something unsuitable and therefore had/has to be avoided. That's less common these days. If you have to name the null pointer, call it nullptr; that's what it's called in C++11. Then, "nullptr" will be a keyword.

NULL is not type safe. For historical reason it was defined as 0 without casting, and the compiler silence warning of casting number to pointer on this special zero.

For instant, you can do:

void* p = 0;

but not this without implicit casting:

void* p = 1234;

the side effect is that it can be abused as number values, as other answer mentioned.

nullptr improve this by enforcing it is a pointer, you can't assign this to an integer. Since the behaviour is changed, a new name is created for backward compatibility.

Also note that, nullptr is handled by the compiler, its actual value is not exposed to user (like zero in case of NULL). It's much easier to have architecture dependent value, say 0xdeadbeef, without affect programmer's code logic.

Without actually sitting in on the discussion in the standards committee, it's hard to say for sure, but I would think because it would break some code that uses NULL in a meaning where nullptr isn't sufficiently compatible. And breaking old code is never a good idea.