diff -u b/core/lib/Drupal/Core/Config/Entity/ConfigDependencyManager.php b/core/lib/Drupal/Core/Config/Entity/ConfigDependencyManager.php
--- b/core/lib/Drupal/Core/Config/Entity/ConfigDependencyManager.php
+++ b/core/lib/Drupal/Core/Config/Entity/ConfigDependencyManager.php
@@ -16,19 +16,20 @@
  * Configuration entities can depend on modules, themes and other configuration
  * entities. The dependency system is used during configuration installation
  * and removal to ensure that configuration entities are handled in the correct
- * order. For example, node types are created before their field storages and
- * the field storages are created before their fields.
+ * order. For example, node types are created before their fields, and both are
+ * created before the view display configuration.
  *
- * Configuration entites need to declare their dependencies, and if they are
+ * Configuration entities need to declare their dependencies, and if they are
  * part of extensions (modules, themes, or profiles), the extension also needs
  * to ensure that the extensions the configuration depends on are present. For
  * example, if a view configuration is part of a profile and the view will not
- * work without a certain field module, the profile must declare a dependency on
- * this field module in its info file. If you find that you do not want your
- * extension to always depend on a particular module that one of your
- * configuration items depends on, you can use a sub-module: move the
- * configuration item to the sub-module, instead of including it in the main
- * extension, and declare the module dependency in the sub-module only.
+ * work without a certain module (for example, a module that provides a field
+ * that the view uses), the profile must declare a dependency on this module in
+ * its info file. If you find that you do not want your extension to always
+ * depend on a particular module that one of your configuration items depends
+ * on, you can use a sub-module: move the configuration item to the sub-module,
+ * instead of including it in the main extension, and declare the module
+ * dependency in the sub-module only.
  *
  * Classes for configuration entities with dependencies normally extend
  * \Drupal\Core\Config\Entity\ConfigEntityBase or at least use
@@ -40,14 +41,17 @@
  * calculated dependency.
  * \Drupal\Core\Config\Entity\ConfigEntityBase::calculateDependencies() provides
  * a good starting point to call from your implementation, as it will discover
- * dependencies coming from plugin bags and third party settings (and as one
- * further note, plugins can declare configuration dependencies in their plugin
- * definitions, with a 'config_dependencies' key). During dependency checking,
- * the entity class's implementation of
+ * dependencies coming from plugins in plugin bags and third party settings.
+ * During dependency checking, the entity class's implementation of
  * \Drupal\Core\Config\Entity\ConfigEntityInterface::getDependencies() will be
  * called; the base implementation will return the array of all dependencies
  * added by calls to addDependency() methods.
  *
+ * Classes for configurable plugins are a special case. They can either declare
+ * their configuration dependencies using the calculateDependencies() method
+ * described in the paragraph above, or if they have only static dependencies,
+ * these can be declared using the 'config_dependencies' annotation key.
+ *
  * Once declared properly, dependencies are saved to the configuration entity's
  * configuration object so that they can be checked without the module that
  * provides the configuration entity class being installed. This is important
@@ -58,18 +62,16 @@
  * When an item that configuration can depend on is removed, such as when
  * uninstalling a module, configuration that is dependent will also be
  * removed. This default behavior could lead to undesirable side effects, such
- * as a node type configuration being entirely removed when the module defining
- * a field it contains is uninstalled. To prevent this, configuration entity
- * classes can implement
+ * as a node view mode configuration being entirely removed when the module
+ * defining a field or formatter it uses is uninstalled. To prevent this,
+ * configuration entity classes can implement
  * \Drupal\Core\Config\Entity\ConfigEntityInterface::onDependencyRemoval(),
  * which allows the entity class to remove dependencies instead of being deleted
  * themselves. Implementations should save the entity if dependencies have been
  * successfully removed, in order to register the newly cleaned-out dependency
- * list. So, in the above example, the node type configuration entity class
- * should implement this method to remove field configurations when field
- * modules are uninstalled, and entity display configuration classes should
- * remove references to widgets and formatters if the plugin that supplies them
- * depends on a module that is being uninstalled.
+ * list. So, in the above example, the node view mode configuration entity class
+ * should implement this method to remove references to formatters if the plugin
+ * that supplies them depends on a module that is being uninstalled.
  *
  * @see \Drupal\Core\Config\Entity\ConfigEntityInterface::calculateDependencies()
  * @see \Drupal\Core\Config\Entity\ConfigEntityInterface::getConfigDependencyName()