I was going to comment on the documentation for this, or rather lack thereof: "At the end of Title::secureAndSplit()". To begin with this is kind of pointless (if they knew what secureAndSplit() did, they'd have read the function and seen the hook already). But looked at another way, this is maybe the same sort of issue as Brion complained about. Hooks should have *logical* functions, they should not just be stuck somewhere in the code. Maybe tomorrow someone is going to rewrite part of Title.php and secureAndSplit() won't exist. When adding a hook, the questions to ask are
1) What functionality do I want the hook to provide to extensions? 2) Where does the hook need to be put to provide that functionality, in current code?
*in that order*. Otherwise you end up with hooks that aren't as useful to extension writers (they don't provide coherent or obvious functionality, and must possibly be looked up manually in the source code), and are prone to become weird when the code structure changes. Look at the two lonely userCan hooks embedded in the rewritten getUserPermissionsErrors(), which do almost the same thing but were formerly in different functions, so they have different interfaces.
Although, the documentation aspect is still significant. Compare it to the description of the hook right below: "called when showing a revision in Special:Undelete". That tells you exactly what it does, based on the hook's functionality, with no need to look at or know the first thing about the source code (well, except that you need to be familiar with the public interfaces of the objects you're given, obviously).