> An identity hash function takes an identity value and produces a simpler integer from it
I would expect an identity hash function to be exactly that: i.e. a trivial function that takes a value and returns that value unmodified (i.e. the identity function).
It happens to describe well this case because the input to the has function itself is the unique identifier and as it is already uniformly distributed, the has function can just return it unmodified.
In the simple case of using memory location as object identity (ie. in system without moving GC) and typical textbook hashtable implementation simply using the pointer as hash value is highly suboptimal, because heap pointers do not have remotely uniform distribution (low order bits are always zero due to allignment constraints, high order bits tend to be constant and usually also zero...). On the other hand you can use more advanced hashtable design that is explicitly tuned for non-uniform hash value distribution. See CPythons dict for cannonical example of that, although it's motivations are somewhat different (the major reason is that in CPython even real hash values of object's content are intentionally non-uniform to allow for simple way of causing integer-valued floats to have same hash value as ints of same value).
In this context, an 'identity hash function' means that it's a 'hash function for an identity value'. It doesn't mean 'a hash function that is an identity function'. It's confusing!
I would expect an identity hash function to be exactly that: i.e. a trivial function that takes a value and returns that value unmodified (i.e. the identity function).
It happens to describe well this case because the input to the has function itself is the unique identifier and as it is already uniformly distributed, the has function can just return it unmodified.