gistfile1.txt

Hi Keith! A couple corrections on your post:

<blockquote>
While developing a migration module, you will often need to make changes to your migration definitions. Because these are configuration entities, you will need to reinstall your module for any changes to take effect.

Additionally, since Drupal 8 beta 2, Drupal modules no longer delete their configuration when they are uninstalled. Therefore, you will need to write a quick uninstall hook to handle this.
</blockquote>

This isn't exactly true. If your configuration actually <em>depends</em> on your module, it will be automatically deleted. In the case of the module you've described here, the configuration is actually owned by (and depends on) Migrate. So if you were to uninstall <em>Migrate</em>, then it would be deleted. For the most part, configuration dependencies are calculated automatically, and if there is a hard dependency, either the config will be automatically deleted, or you won't be able to uninstall the module until content that depends on it is deleted. (Note that we're still fixing some bugs in this area of Drupal 8.)

In the case of your module, a simple fix would be to use the "enforced" dependency key to indicate that you want the configuration to depend on your module even though there's no code in your module that it actually depends on. (It's already a bit strange that Migrate uses config entities in the first place, but that's another whole conversation!) For more details on how configuration dependencies work, see: https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Config%21Entity%21ConfigDependencyManager.php/class/ConfigDependencyManager/8

Also, a quick note. You gave the example:
<code>
function migrate_custom_uninstall() {
  db_query("DELETE FROM {config} WHERE name LIKE 'migrate.migration.custom%'");
  drupal_flush_all_caches();
}
</code>

You should never do this! It completely circumvents the configuration and entity systems. It could lead to broken dependencies, orphaned data, hooks not firing, and all sorts of other problems. Also, the storage of active configuration in the database is core's implementation since March, but it's also possible to use other storages, so that code would also not work with active config that wasn't stored in the primary site database. Instead, use the Entity API to delete config entities:
https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Entity%21EntityStorageInterface.php/function/EntityStorageInterface%3A%3Adelete/8

In fact, in general, direct database queries are a thing of the past in Drupal 8. In most cases, there's a decoupled storage API you can and should use instead. :)