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).