Two wrongs don't make a right. The fact that "a".hash == "\0a" hash is an issue with the hash function. nothing else. Seeding the hash function so it is unique for each process does not solve the issue.
Recent versions of Ruby also use a much better hash function. Java's hash function on strings has a slightly less trivial process for generating collisions, but it's still very easy to generate enough of them to pose a DoS risk.
Edit: actually, Java's String.hashCode() has exactly the same problem — prepending null chars doesn't change the hash code. And because the hash function is actually part of the Java standard library docs, it will probably never be changed (unlike Ruby's).
How in the world would does the described issue with hash codes on distributed systems fix the issue of hash collisions in a request? Usually the attacker would send multiple parameters for "a","\0a","\00a" in a single request anyhow.
Sorry, I think I misunderstood your first post then. By "the issue", I thought you were referring to the issue that the randomized-hash set out to solve (DOS attacks/pathological performance due to predictable hashes)
