Introduction of new hooks in stable Drupal releases should be allowed and encouraged.

Changing things in stable Drupal releases always needs to be done with care. So far we only do this for bug fixes. See the backport policy (and feel free to improve this article). We don't want to cause conflicts with existing contrib or custom code (which can be php, html, css or javascript), and we don't want to unexpectedly change the appearance or behaviour of existing sites running Drupal.

As has been pointed out in several occasions, including a blog article by Dries, many Drupal users don't like to wait for a future version of Drupal, for a simple problem to be solved.
http://buytaert.net/8-steps-for-drupal-8
step 6: "Backport small changes to stable releases".

The solution, as I see it, is to introduce new hooks, that allow to solve the issue in contrib.
Hooks don't break anything (*), and they don't change appearance or behaviour. They do nothing, unless a module comes along and implements that hook.

-----

The only problem with new hooks is name clashes.
And the solution to that is reserved namespace conventions, similar to the "__" prefix for PHP magic methods. In D8 this could be based on PHP namespaces, for D7 I'm not sure.

I would appreciate to get this for D6 already, but I'm afraid we would get name clashes in many cases. On the other hand, contrib modules introduce new hooks every day, and so far I don't see people complain about conflicts with hook names.

I guess the following will solve the problem, but I'm not sure if it's bullet-proof:
#548470: Use something other than a single underscore for hook namespacing

------

A little explanation about hook nameclashes:

1. Imagine a module called "mymodule", and another called "foo". This "mymodule" has a function called "mymodule_foo_bar()", which is just a normal function. Now we upgrade to a new version of "foo" (becaue the old one is buggy or insecure), which introduces a new hook called "hook_foo_bar()". Suddenly the "mymodule_foo_bar()" function is seen as a hook implementation. Which can cause all kinds of trouble. This can be avoided with the _hook_ naming convention mentioned above.
2. Imagine a custom hook called "hook_foo_bar()", defined in a custom module "foo", that is not published anywhere. Now a Drupal core or contrib introduces a hook with the same name. Poof. This can not be avoided with the "_hook_" naming convention, but it's a quite rare case.

-----

So, my point is not to write a duplicate of #548470, but to change the backport policy to allow new hooks in stable releases.