The future of procedural and hooks: Namespaces? Pure OOP?

Hi,
while the conversion of OOP code to PSR-0 for D8 is making progress, the original requests for namespaces were all about procedural and hooks:
http://drupal.org/node/867772

There have been arguments by the PSR-0 people that this would be a too difficult design task.

There have been other arguments that it is not worth the trouble, and we should rather move our procedural code to OOP. Imo this is certainly a possibility, but a lot of questions about this are not answered or even discussed.

Possible directions

So, what is the future of procedural and hooks?

EDIT:
To make this a bit different from old discussions on the issue queues: How will procedural and hooks in Drupal look like in 5, 7 or 10 years from now? Which options are desirable long-term, which are not?

1) Namespaces, e.g. like this:
Drupal\mymodule\hook_menu() for hooks
Drupal\mymodule\foo() for regular functions
http://drupal.org/node/1428592

2) Leave things like they are for now, but slowly move away from procedural altogether.
This leaves the question of an OOP equivalent to our hooks system. Yes, there are patterns like "observer"/"listener", but these require active registration of the listening component. I imagine that's going to be more ugly than today.

Also, doing this too fast will likely result in poor quality OOP code.
Personally, I like the possibility to have a mix of OOP and procedural.

3) Don't do anything.
This leaves the following problems:
- Nameclash bugs: So far we survived. I only remember one atm, and this was fixed.
- Nameclash paranoia: Giving modules and functions awkward names to avoid collisions, even with hooks that might only exist in the future.
- Nameclash with 3rd party code: Few people dare to mix Drupal with other procedural code projects, so again we have survived so far.

4) Keep the procedural, but use a new hook separator like '__' or 'hook'.

Types of nameclashes

Just to clarify, here are the typical nameclashes we are talking about.
Existing protection mechanisms are "module name as prefix for functions" and "inventor module name as prefix for hooks" (or just name the hook like the inventor module). Both of these do not protect in the following cases:

a) Regular functions collision:
function foo_bar_shoe() could be declared both by module "foo_bar" and by module "foo".
I think this bug is the least likely to occur, and also the easiest to detect and fix.

b) Unintended hook implementation:
function foo_bar_shoe() will be interpreted by module "bar" as an implementation of hook_bar_shoe() by module "foo", even if the author of "foo" did not know about hook_bar_shoe().
This is more likely to happen if the module name of "bar" is too vanilla to be recognized as a module name.

c) Hook ambiguity:
function foo_bar_shoe() could be interpreted as an implementation of both hook_bar_shoe() and hook_shoe(). The author probably intends only one of them.

d) Hook inventor ambiguity:
hook_foo_bar_shoe() could be invented in parallel by module "foo" and by module "foo_bar" and even by module "foo_bar_shoe" (if we allow hook name = module name).
This is quite unlikely to happen, though.

I think the most likely of these is unintended hook implementation (b).

But, even if none of the above actually happens, we still have the issue of "nameclash paranoia" when naming functions and modules. E.g. I would not name a module "admin_menu" or "menu_block" today, rather "adminmenu" or "menublock", because "menu" and "block" are too commonly used in Drupal identifiers.

EDIT:

I suspect a lot of this discussion will be a repetition of things already said in the issue queues.

To give this a somewhat new direction, I would ask, how will Drupal look like in, say, 5 years from now?
Will there be any procedural code left? If not, how will the replacement of our procedural stuff look like?