Obviously, it's not a complete merge solution. I haven't tested it thoroughly, but maybe this will help.
I'll use a true-life example: after about 6 months, a user decided he wanted a new handle, so he abandoned the old account (we'll call it 'Bill') and created a new username (let's call this one 'Hoohah'). Now, to answer your questions...
1. I renamed the original account ('Bill') to Hoohah. As soon as I did that, Hoohah "inherited" everything from Bill. Hoohah will now need to log in with Bill's password. At login, Hoohah will now find all of Bill's messages in his inbox, including new, unread messages delivered to either account.
2. Unfortunately, this script is not a true merge, so the post total for the resulting account will not be incremented--in this example, Hoohah's new post total will equal Bill's. My solution was to note Hoohah's total beforehand, then manually increment Hoohah's new total (Bill's old total) by adding Hoohah's total (the one that existed before the change) using a db tool like PHPMyAdmin. More laborious, untidy, but it worked.
Post totals is a relatively minor fix. The real value of the changename script (besides changing the username) is this: every post in the database made using either account will now be attributed to (and linked to) Hoohah.
3. As noted earlier, PMs shouldn't be a problem. According to my test, the only problem is that now any PM's in somebody's inbox from Bill can't be answered (since 'Bill' now a nonexistent account). However, unless there's like 100 PM's from Bill out there, this can be fixed with a tool like PHPMyAdmin without too much fuss.
Bottom line: this hack is not ideal for merges, yet it does most of the job. (But, realistically, how many times will you need to merge?) Moreover, I'm sure a couple more basic SQL commands could be added to take care of the current shortcomings. I just haven't gotten around to it . . .
