module_enable() exposes module hooks before the module's schema is installed

Currently, the sequence of module_enable() is as follows (once it is determined that the module needs to be installed):

1. The module's main code file ("*.module") is loaded.
2. The module's install file ("*.install") is loaded.
3. The database is updated to reflect that the module is installed.
4. The cache of which modules are enabled is cleared.
5. The cache of which modules implement what hooks is cleared and rebuilt.
6. The file registry ("system" table) is updated.
7. The database schema cache is cleared.
8. The theme registry is rebuilt.
9. The module's schema is installed.

(The steps of largest significance to this issue are bolded.)

There are several problems with this approach:

1. If the module fails to install, it's marked as already having been installed in the database, but without its schema. Other modules that depend on the module might install but have errors as soon as they call API exposed by the problematic module that relies on the schema.
2. Any modules that alter the registry (like ctools) are free and clear to invoke hooks on the module being installed (for example, RDF) without realizing that the module's schema is not yet available. Or, more likely, a module like ctools will invoke normally innocuous hooks in other modules which, in turn, invoke hooks on the module being installed.

As a result of this issue, we have a problem with a distribution we're preparing that will inexplicably fail to install depending upon the order of the modules being installed. For example, if we install Feeds, which depends on CTools, then install RDF, the install fails.

Here's a sample stack:

405:_rdf_mapping_load(commerce_coupon,discount_coupon)
1101:rdf_entity_info_alter(Array,,,)
7682:drupal_alter(entity_info,Array)
170:entity_get_info()
533:_feeds_feeds_plugins()
686:feeds_feeds_plugins()
649:ctools_plugin_process(Array,feeds,feeds,modules/contrib/feeds)
264:ctools_plugin_load_hooks(Array)
33:ctools_get_plugins(feeds,plugins)
597:_ctools_registry_files_alter(Array,Array)
1101:ctools_registry_files_alter(Array,Array,,)
65:drupal_alter(registry_files,Array,Array)
3228:_registry_update()
452:registry_update()
1609:module_enable(Array,)
:_install_module_batch(rdf,RDF,Array)
284:call_user_func_array(_install_module_batch,Array)
161:_batch_process()
80:_batch_do()
449:_batch_page()
339:install_run_task(Array,Array)
77:install_run_tasks(Array)
26:install_drupal()

This is Major because there's no good way around it at install time without directly manipulating the order that modules get installed. I'm tempted to say it's Critical because it can pop up without warning when installing modules on a live site in the wrong order, and requires a lot of debugging to nail down.