I don't really see how making a separate table for just the authentication process is going to help much. Nobody's going to bother trying to brute-force an MD5 key

Well, as I mention first off, his basic solution is Good Enough. What I'm saying is in part about security, true, and I'll touch more on that point in a moment. But I also find the idea of attaching an extra column, even a BOOL, for what amounts to a one-off to be a waste of space. In a table that's referenced many times a day, it's just one more thing to manage (unless you choose to leverage it into a level/auth system, and even then...) Once the user is verified, it's useless, and that's not my style, nor one I generally recommend. Call me The Normalizer, if you must. :)

You'll also note that I didn't mention MD5, or any secure hash routine, by name. I must call out one error that I did in editing the original response; the password stored in the Temp table should, indeed, be encrypted -- NO cleartext passwords! But I don't mention a scheme, and that's in part because MD5 is crackable in a non brute-force fashion, as is SHA-1. Now, in my opinion, you're right about MD5 being Good Enough for an authentication URL; it's not a huge deal for this guy's project, nor is SHA-1. But yea, the data that's actually stored in the DB for the password hash itself should be something stronger...and I confess that I didn't want to scare the petitioner half to death. However, I did what to give ideas, and hints on building a solid, flexible foundation for their auth scheme.

One more point, since you touch upon it. Most modern email clients can handle long URLs, no problem. Some, however, cannot, and some people are stuck on them, not to mention the potential of mangling. Because I've seen it happen, I firmly believe that the shorter the URL, the better off the end user is in terms of functionality. And the the less data you pass, esp. over GET, the better off you are in terms of internal security (see any paper on SQL injection for just one set of reasons why).

Either everything should be in one table for the sake of simplicity (and records accessed by ID) or the entire registration record should be in the temp table, and only moved to the primary table once it's been activated.

I like, and would employ, your 2nd solution if I have an application with many "false positives" -- people (or machines) registering, but never verifying. At that point, it becomes cleaner to keep your main user table tidy in that fashion, and I'm glad you brought it up as an option, as well.