You’ve run into what you believe to be a problem, however, if you were to look at their hash codes in the same execution you’ll find that they’re not identical but instead rely on their order of usage:
Console.WriteLine("{0} {1:08X}", typeof(string), typeof(string).GetHashCode());
Console.WriteLine("{0} {1:08X}", typeof(Program), typeof(Program).GetHashCode());
// System.String 02BF8098
// Program 00BB8560
If I run that same program again, swapping their order:
Console.WriteLine("{0} {1:08X}", typeof(Program), typeof(Program).GetHashCode());
Console.WriteLine("{0} {1:08X}", typeof(string), typeof(string).GetHashCode());
// Program 02BF8098
// System.String 00BB8560
This is a non-issue at runtime as the returned values do not violate the rules for implementing Object.GetHashCode.
But, as you noted this behavior seems curious!
I delved into the source and found the implementation of Type.GetHashCode is foisted off onto MemberInfo.GetHashCode, which is again foisted off onto Object.GetHashCode which calls RuntimeHelpers.GetHashCode(this).
It is at this point that the trail goes cold, however, my assumption is the inner workings of that method creates a new value, mapped per instance, based on the order of calls.
I tested this hypothesis by running the same code above with two instances of Program (after adding a property to identify them):
var b = new Program() { Name = "B" };
var a = new Program() { Name = "A" };
Console.WriteLine("{0} {1:08X}", a.Name, a.GetHashCode());
Console.WriteLine("{0} {1:08X}", b.Name, b.GetHashCode());
// A 02BF8098
// B 00BB8560
Thus, for classes which do not explicitly override Object.GetHashCode, instances will be assigned a seemingly predictable hash value based on the order in which they call GetHashCode.
Update: I went and looked at how Rotor/Shared Source CLI handles this situation, and I learned that the default implementation calculates and stores a hash code in the sync block for the object instance, thus ensuring the hash code is generated only once. The default computation for this hash code is trivial, and uses a per-thread seed (wrapping is mine):
// ./sscli20/clr/src/vm/threads.h(938)
// Every thread has its own generator for hash codes so that we
// won't get into a situation where two threads consistently give
// out the same hash codes.
// Choice of multiplier guarantees period of 2**32
// - see Knuth Vol 2 p16 (3.2.1.2 Theorem A).
So if the actual CLR follows this implementation it would seem any differences seen in hash code values for objects are based on the AppDomain and Managed Thread which created the instance.