Configuration change data loss prevention functionality inconsistent, restrictive

Problem/Motivation

Protection against accidental data loss is implemented inconsistently and makes it difficult and time consuming to make and deploy content model changes. Consider a few examples:

Via the Drupal UI...

Try to delete a content type with existing nodes.

Drupal refuses: "Example is used by 1 piece of content on your site. You can not remove this content type until you have removed all of the
Example content."

Try to delete a vocabulary with existing terms.

Drupal allows with warning: "Deleting a vocabulary will delete all the terms in it. This action cannot be undone."

Try to delete a field with data in it.

Drupal allows without any mention of the field containing data.

Try to change configuration of a field with data in it.

Drupal refuses: "There is data for this field in the database. The field settings can no longer be changed."

Try to do deploy prohibited changes via configuration import and the whole operation will abort:

$ drush config-import -y
 Collection  Config                                         Operation
             core.entity_view_display.node.example.default  delete
             core.entity_view_display.node.example.teaser   delete
             core.entity_form_display.node.example.default  delete
             field.field.node.example.body                  delete
             field.field.node.example.field_example         delete
             node.type.example                              delete
[error] Import the listed configuration changes? (y/n): y
Drupal\Core\Config\ConfigImporterException: There were errors validating the config synchronization. in Drupal\Core\Config\ConfigImporter->validate() (line 728 of
/var/www/example/docroot/core/lib/Drupal/Core/Config/ConfigImporter.php).
[error] The import failed due for the following reasons:
Entities exist of type Content and Content type Example. These entities need to be deleted before importing.

The impact is that any project team tasked with significant or ongoing changes to the content model will spend a lot of time puzzling over inconsistent error messages, deleting content from local dev environments in order to make configuration changes, and writing update hooks in order to deploy them. The most skilled of teams will be slowed considerably. Junior teams are likely to get blocked.

Proposed resolution

1. Settle on and consistently implement a pattern in the UI that...
   1. Warns when an action will cause data loss.
   2. Provides an option to accept the loss (e.g., "Delete all Example nodes and continue.").
2. Provide an override for the ConfigImporter validation routine allowing configuration changes causing data loss to be imported so that Drush and other tools can use it.

Remaining tasks

TBD

User interface changes

TBD

API changes

TBD

Data model changes

TBD