Modules should easily be able to provide plugin implementations on behalf of core modules

This was very easy to do in Drupal 7 with hooks:

function mymodule_get_stuff_info() {
  $info = module_invoke_all('stuff_info');
  drupal_alter('stuff_info', $info);
  return $info;
}

/**
 * Implements hook_stuff_info() on behalf of node.module.
 */
function node_stuff_info() {
  return array('node' => array('class' => 'NodeStuff'));
}

/**
 * Implements hook_stuff_info() on behalf of comment.module.
 */
function comment_stuff_info() {
  return array('comment' => array('class' => 'CommentStuff'));
}

This was nice because this system just "worked" and the implementations were either called or not if node or comment were enabled or not respectively.

In D8, hooks are typically plugins now. After talking in IRC with EclipseGc and catch, it seems there is a 'provider' key that I can add in a plugin annotation which is essentially the module name that 'provides' that plugin. You can provide that key if you want, but nothing in core really does because it is automatically generated for you by AnnotatedClassDiscovery::getDefinitions(). So this means anything returned by AnnotatedClassDiscover is assumed to be an enabled module, when in fact, this could very well not be true. EclipseGc recommended a patch to DefaultPluginManager::findDefinitions() that validates the 'provider' key if it exists to check if that module is actually enabled. Which would be the easiest way to provide plugins on behalf of core modules, from my contrib module.

Also we need to document this 'provider' key (#2079245: explain the extra items that are passed to PluginBase::__construct() in $plugin_definition) because I could not at all know what things I could pass to an annotation at all. That code is incredibly hard to follow.