The original mistake by the standards committee was allowing implicit conversions from integer to pointer. I.e. allowing NULL to be defined as simply 0.
If NULL had been defined always as ((void *) 0) then I don't see that we would have had a problem.
But that's all history now and in this situation I can see that adding nullptr becomes a reasonable way out.
It's ironic though that the fix for the different ways to write null is to add yet another way.
You're missing the whole point.
As per the C standard, NULL is an implementation-defined null Pointer constant.
Macros are resolved in the preprocessing step. The compiler does not know what a macro is. What the compiler knows is whatever the preprocessor passes off in place of the macro. This means the compiler only sees a constant, and has no way to tell what that constant means.
If instead of passing random pointer constants you pass an actual type, now the compiler can tell more things.
> If NULL had been (...)
Irrelevant. The whole point is that it wasn't the committee looked at the problem, and it determined that using a dedicated type is safer, more powerful, and more elegant than passing magic numbers around.
I'd categorize nullptr as 'mostly harmless'