There are a number of rebuilds that can be done as static code analysis. The advantage is, of course, breaking a lot of chicken-egg problems. The class registry is one. The oft-debated hook registry is another. Right now we are building this on-the-fly using the cache layer but this is not quite cache. This of course requires #548470: Use PHP native namespacing in hooks instead of wonky _. For radical simplifying we could do the theme registry as well -- we are already passing in a single variables array and so hook_theme() is much less necessary. So based on the name of functions and the .tpl.php we can build up the theme registry. It'd be great to have CMI for storing this. We will figure it out what to use instead for now.

When you enable a module then a rebuild.php runs. If you add a new theme function / hook, you run the same.

Comments

Very interested in working on this.

What we are talking about is basically a hook registry.
And this could be very useful for several reasons:

1) If we had a list of all hooks, we could have the ability to disable certain hooks, or certain module's hooks, or hooks of certain types (all form_alters for example).
This would be very useful for debugging, while allowing us to kill disabled modules: #1199946: Disabled modules are broken beyond repair so the "disable" functionality needs to be removed.
2) It would allow us to move to a world where not all modules are loaded all the time.
Drupal could just load the modules that have implementations of hooks fired, that need to supply content, and their dependencies (we could have two levels of dependencies, where the first one is for loading modules whose functions you use, while the other is for modules on which you rely, like Views for powering your listing view).

As chx said, we first need a clear way of distinguishing which functions are hooks. Naming, namespaces, registration, you name it.
Another important step is killing all hooks that shouldn't be hooks (but callbacks, or plugins, or whatever. I'm looking at you, Field API).

I could imagine a table with a row for each hook (hook type, module name, and file perhaps. For example: form_alter, commerce, commerce.module).
200 modules, 30 hook implementations per module, that's 6 thousand rows, which is not much, and the real number would probably be lower.
Then we could have a cache per hook type, so we could fetch all hook_boot() implementations in all go, etc.

Closely related or even duplicate of: #1668892: Enable secure compiled information on disk

Not a duplicate, but related yes. Compilation is a specific rebuild use case, while this issue we're speaking into is generally speaking about all rebuilds.