This hook is just plain weird.
* Return value on abort destroys the entire data set
* Whitespace is bad
* It's very unclear what this would be used for
* This is a low-level function that's going to get called very often, and the hook is in a place that has little clear function. It's unclear what a general hook would want to do with it.
A few notes:
* This seems to drop the 'action=success' page in favor of dumping all the output directly on the POST response. That's probably necessary, but tends to cause annoyances with back/forward navigation (warnings about re-POSTing data etc)
* The subpage checkbox is shown on the form based only on the target page's namespace. This means it'll show for the vast majority of, say, talk pages which don't have any subpages. To be consistent with the talk namespace, it should be kept hidden if there aren't any.
* Subpages may exist for a talk namespace while not existing for the article namespace. When moving an article with its talk, and the talk has archive subpages, it would probably make sense to do the moves -- but no check will show here due to the check only on the article space.
* There's a couple copy-pasted instances of $something ? ' checked="checked"' : '' ... since these are passed to a function looking for a boolean, they should just use the boolean $something. :)
* I see some unnecessary uses of =& ... this is a PHP 4-ism and not needed here.
* This query's kind of creepy:
SELECT /* MovePageForm::doSubmit WikiSysop */
page_id,page_namespace,page_title FROM `page` WHERE 0 = 1
* Generally speaking, there may be a _lot_ of subpages. English Wikipedia Main_Page will net you 169 total including itself, talk, and all subpages. How safe is it to move potentially thousands in one request here?
* Say "log in / create account" if an anonymous user can create an account, otherwise just "log in", consistently across skins. (Currently Monobook always says "log in / create account " and non-Monobook always says "log in".)
* Add a cache so that calling getcategorycount for the same category many times won't stupidly repeat the same query over and over. Currently an early return avoids incrementing the expensive function count in this case, so technically this makes things *slower*, not faster, but that can be tweaked if anyone cares.
