Maybe the message should not be Missing hash key but something like Invalid key type.
When there's a block, it would be technically possible to return a value for any key, as long as it has the right type. So the problem is that first we didn't find the key in the hash, and second we couldn't use it for the default block. It might make sense for the latter to take precedence...

How about "Invalid key type: expected #{K}, got #{key.class}"

Isn't this solution going to create issues re: lack of symmetry of the error messages? Why is the type checking being done only when the block is being given and not in other cases? The same method will return different errors depending on the internal state, violating the principle of the least surprise.

Couldn't the error message could outline the key type mismatch regardless of the block?

Another hint in favor to #8893 IMO.

A maybe surprising property is that type identity is not a requirement for hash lookup.
When looking up in the hash, it's not even necessary that the lookup key matches the hash's key type. It can match values of different types, as long as they're equal in #== and have an identical #hash.
Matching type is only necessary when calling the default block. So I think it's adequate to have this special error message about incompatible type only when a block is given, because at that point it's no longer about matching to a key in the hash, but calling a proc which expects a specific input type.

@straight-shoota The error message doesn't mention block at all though which makes this confusing.