I don't know the story, but the logic behind it is simple: If you want to guarantee no one depends on GetHashCode staying static between runs of an application, change it all the time.

But now I can circumvent this hack by xoring with ThisAssembly.DailyBuildNumber again. :)

I think the story is even simpler than that as the code in question is prefaced with: #if DEBUG

The shipped product doesn't include this "randomness".

Also is it not for hash collision protection, which can end up hurting the runtime of many algorithms, causing a DoS?

No, it has no effect on hash collisions. Two hashes that are equal before being xored with the daily build number will still be equal afterwards.

It won't help much there as the number is static for a particular build.

The hash randomization for security is above this part of the code.

IIRC, a few yeas ago appeared a denial of service attack, probably originally for Phyton, but it was ported son to other languages.

The idea is that the hash is good enough for normal list, but it's not a cryptographic hash and it's easy to find collisions. Then you can make a lot of requests with strings that has the same hash value. Now the hash operations are O(N) instead of O(~1) and everything is slower.

Using an unpredictable hash calculation makes this attack more difficult.

Your typo can be easily fixed by a Python one-liner:

    >>> (lambda w:w[2:]+w[:2])(''.join(sorted("Phyton",key=lambda c:math.sin(ord(c)^50))))
    'Python'

It's in a #if DEBUG statement so it would not change. Historically, even if they shipped the debug symbols, the assembly would have been built in release. Now, I suppose you could build it in debug.