Why ssh validates host keys using the exact name you supplied
One of the little things that ssh does is that it checks and maintains host keys using exactly and only the name you used on the command line; it doesn't canonicalize the name. (Well, not much; these days it will also try the IP address that the name resolves to.)
The problem around here is that the names of machines can be specified in all sorts of different ways, because of domain search paths; often we have bare name, bare name plus the subdomain, and then two versions of the fully qualified hostname (because we have two top-level domain names, which is its own headache). This causes heartburn if you insist on strict host key checking, or in general if a host key has to change; users may be tripping over alternate names with old keys for some time to come.
(And then there's trying to write $HOME/.ssh/config stanzas that apply to a particular host, no matter how you're typing its name today.)
When I started stubbing my toe on this today I was all ready to curse ssh for not canonicalizing the hostname before it did host key matching and stuff; using only canonicalized names would make a bunch of things simpler. Then I thought about it some more and realized that it would also make ssh less secure.
The problem is that there is no way to tell if the canonicalization that you're doing is the canonicalization that the user expects to happen; if ssh was to canonicalize silently, it would be open to attacks (or just accidents) that change the canonicalization behind the user's back. Not canonicalizing hostnames when storing and checking host keys means that ssh can assure people that if they do 'ssh foobar', either they are getting the exact same foobar that they did last time, or they are going to hear about it. Loudly.
This is the past of least surprise, although a certain amount of annoyance.
(Yes, canonicalizations can change accidentally, or at least without malice. Sometimes the results can be somewhat exciting.)