Orphan/obsolete keys and sub-keys *within* configuration objects are retained *forever*

Agreed with #2.
I'll leave it to someone from the CMI team to RTBC thoigh :-)

IMO, that's also one of the reasons why we can't sipport module B's settings about module A's ConfigEntities to be stored within the CMI files for those ConfigEntities (i.e comment settings for 'article' to be stored within node.types.article.yml). Too many chances of having the external data wiped out.

@sun : so that would be a a mechanism provided by ConfigEntityBase ? Is there an issue for this already ?

This is the issue: #1783346: Determine how to identify and deploy related sets of configuration.

Alright, added my thoughts on the topic over there, then.

+++ b/core/modules/config/lib/Drupal/config/ConfigStorageController.php
@@ -270,6 +270,10 @@ public function save(StorableInterface $entity) {
     $this->preSave($entity);
     $this->invokeHook('presave', $entity);
 
+    // Clear out any possibly existing keys in an existing configuration object,
+    // so any potentially stale keys are removed.
+    $config->clear();

I strongly disagree with this change! This should be done before presave hooks execution

This could kill all ability to inject other data into ConfigEntity - we have the same with drupal_write_record()

@sun Could you please elaborate? Reading though this issue I am at a loss with your comments in #11. Thanks.

#2: drupal8.configurable-clear.2.patch queued for re-testing.

Related: #1822048: Introduce a generic fallback plugin mechanism

We have reason in Views to possibly want unavailable keys to be stored in the config.

I agree about disregarding static config objects and the patch looks good, but I'm not clear on xjm's comment about why they would want this data for missing handler management. Can you give an example of how this would present a problem?

Here is a re-roll

I'm not sure how this affects us with broken handlers, this is data we want to store, so we'll store it.

This patch will essentially clear configuration before saving so you only have relevant data that was on the entity? That's totally fine for us. Its just a part of handler data , same as any other option we have in there. Missing handlers are stored no differently.

I thought it would be helpful to note that this patch was discussed quite a bit in #1785560: Remove the sorting of configuration keys and that the code from this issue was included in a few of the patches from that issue, such as in comment #36 from that issue. That code was removed after webchick described it as killing kittens and others suggested this patch might be solving a "theoretical" problem.

One of the most relevant comments from the other issue was #45 in which @alexpott describes a conversation he had with @sun.

To me, the idea of clearing out config objects before writing new data into them makes a lot of sense and would reduce the likelihood of retaining unwanted config data.

Discussed this issue at MWDS with @alexpott and @mtift. We agreed that, while this is not ideal, the responsibility is on the configuration provider code to clean up their stale data. It's not nearly as bad as in D7 and prior because the files are namespaced and so forth. It also hasn't really come up as an issue during the course of the D8 cycle.

Still needs work for tests

This hasn't come up in the past 2 years either. Bumping to 8.1.x, but I think it could be closed.

It kind of has now in #2648956: Editing a view leaves old keys hanging, results in invalid schema. But maybe that issue is the final argument for saying that this is something that the specific config entity has to care about and we'd wont fix this?

On the basis of the last two comments we're expecting providers to clean up after themselves now