Currently the hook cache is an array of the format $module_name => $group.
We also know that the hook system is fragile.
sun suggested to allow an alternative format with Drupal\$module\Hook::foo() (and other proposals existed before that):
#2237831: Allow module services to specify hooks
As a preparational step before any such move, I suggest to change the hook cache so that it can be filled with arbitrary callbacks.
For the start, these can be added with hook_module_implements_alter().
Later we can add patterns like Drupal\$module\Hook::foo() or Drupal\$module\hook_foo(). This could even happen post-release, since it would only extend the API and not break it. (unless a module already defines a class that matches the pattern.. duh)
The change of the hook cache brings only one API break: It changes the structure of hook_module_implements_alter().
hook_hook_info() will continue to work as it does today.
Challenge: We still need a way to store which files should be included for a hook implementation. We may want to store the module name and the file path relative to the module dir. This way, things don't break if modules are moved around.
This means the simple array structure of $module_name => $group no longer does the job.
Note: #2263365: Second loop in module_implements() being repeated for no reason. should be fixed first!