OK, so I followed Pete's advice, and tried an upgrade from Core 7 to Core 8 via yum (yes, I know that Core 9 will be out shortly, but I figure it would probably be a mistake to go directly from 7 to 9, based on previous experience). Everything went fine until the end, when it failed with this message:
--> Processing Conflict: glibc-common conflicts glibc < 2.7
Error: No Package Matching glibc.i686
So, now what?
[Evening update]
OK, I ended up having to completely blow away glibc. Unsurprisingly, it broke my installation, with no obvious way to fix it. But it allowed me (finally) to do an ftp upgrade via a rescue CD. I'm now running FC8.
Google is your friend. You have both old and new versions of the glibc libraries installed. Remove the old one and try again.
See, this sort of thing is why I simply never use packaging systems in linux, and don't upgrade things without a specific reason.
I've seen yum/rpm do it; I've seen apt/dpkg do it, and from what I hear from the lunatics that use gentoo, emerge can do it too.
Bad or ridiculous dependencies (want this console software? well, you gotta install a complete X system, because the jackhat that made the package for the distribution decided that the X frontend to that was so vital it should be baked in), terrible error-reporting... a mess.
But of course that does you no good - if Orion's comment wasn't helpful, I'd fire up an irc client, and go to #fedora on the Freenode network.
Post-factum, I suspect it was either an old glibc like Origon surmised, or a plain bug. The glibc instances (like kernel and a few other packages) are helpfuly (or "helpfuly") made non-conflicting on purpose: you can have several of them installed simultaneously, should your application mix require it. One can keep them unknowingly for years, until an upgrade stumbles.
Notice that glibc.i686 was a 32-bit version, and your installation was a 64-bit one. Some odd 32-bit package pinned an ancient glibc, I would guess. Maybe Sun's Java (which only comes in 32-bit version, if you want Web plugin). Removing that one package should not in any way hose the whole installation, because x86_64 uses 64-bit binaries in preference (unlike, for instance, PPC).
We will never know what it was exactly. I should be glad it ended well.
Since nobody said it: glibc is the GNU C language library and just about everything important is in C and more often than not uses glibc. So it's almost always a crucial piece of Linux systems and messing it up usually makes everything pear-shaped sooner or later.
Not trying to sound like a know-it-all: I run Xubuntu for a reason ^_^;
Debian and Ubuntu have aptitude, which for me does an excellent job of not only warning before installation if there is a dependency conflict, but provides a list of actions to scroll through ("keep foo in current state", OR "upgrade foo and bar" etc.) to resolve the issue. I don't know yet how well it handles version upgrades. I will find out next week.