You have null be a keyword that means NULL (a value which could never be held by any variable). Doesn't have a literal definition, just a symbolic one to the compiler.

It would have to be a compile time thing. Its hard to do if you never plan for this sort of feature ahead of time.

Perl has a special "undef" flag on scalars, its not 0, its not any kind of null or "" (empty string), its special and perl complains loudly if you use undefined variables (if you tell it to of course, but I always do, it finds so many bugs, and has trained me to not use undefined variables).

Obviously not, it was just for comparison's sake. As I mentioned, anything C++ could do would have to be magic compiler syntax that ends up being mostly useless since you wouldn't be able to check the undef/nullity state at runtime with any sort of accuracy.

That doesn't change the fact that C++ does not have anything like variable type flags; a long int may be 32 bit, say, and nothing more or nothing less, and each of those 32 bits are accessible. There is no "metadata" to say "this is null". In other words, null is indistinguishable from a particular value that datatype can contain, such as the number zero.

// nullcmp.cs
using System;

namespace NullCmp
{
    public class Program
    {
        private static int Main(string[] args)
        {
            System.Console.WriteLine("(null==0)={0}", (null == 0));

            return(0);
        }
    }
}

prompt>csc nullcmp.cs
Microsoft (R) Visual C# 2005 Compiler version 8.00.50727.1434
for Microsoft (R) Windows (R) 2005 Framework version 2.0.50727
Copyright (C) Microsoft Corporation 2001-2005. All rights reserved.

test.cs(10,46): warning CS0472: The result of the expression is always 'false'
        since a value of type 'int' is never equal to 'null' of type 'int?'
prompt>test
(null==0)=False

Interestingly, apparently "null" is of type "int?". I'm curious how it is stored under the surface.

prompt>csc nullcmp2.cs /unsafe
Microsoft (R) Visual C# 2005 Compiler version 8.00.50727.1434
for Microsoft (R) Windows (R) 2005 Framework version 2.0.50727
Copyright (C) Microsoft Corporation 2001-2005. All rights reserved.

prompt>test
(0==null)=True
(0==null)=True

I may have done something wrong or perhaps the results don't represent the actual implementation, but it seems possible that C# is storing null as 0. There's a good chance I'm overlooking something or lack the understanding to see the difference. I don't actually know how pointers or unsafe code works in C# yet so this is all just a guess.

Not true. Conceptually, Null is something very different from zero, and most languages (but not C / C++) treat it as such - even though in many of them, NULL (or the language equivalent) compares equal to zero due to implicit conversions.
PHP even distinguishes between Null and undefined; although the difference is somewhat esoteric, it does make sense in the PHP universe.

In C#, null is of type Null (a class that can only ever carry the null value). Since you're comparing it to an int, though, the compiler applies an implicit conversion, using a type that can both be assigned a null value AND be equality-compared to an int. The best match for these constraints is a nullable int (int?), so that's what the null in your example is treated as. If you were comparing it to a bool, you'd get a bool?. For a string (which is a reference type and thus nullable by default), you'd get a string (not a string?).

In fact, using unsafe code, it is. In unsafe mode, C# allows pointers which work pretty much like those in C++, and they can be cast to and from integers - just like in C++. And in that case, a null pointer (as opposed to a null reference!) IS stored as integer zero, and converts to 0 when cast to int.
For reference types, this doesn't work, because C# doesn't allow pointers to reference-typed objects.