Incorrect changes in configuration export with multiple splits enabled

Problem/Motivation

When having multiple active splits that have the same configuration files overwritten between recipes, when exporting configurations, files from several recipes are deleted and undone modifications are displayed.

Steps to reproduce

Drupal versión: 9.2.11
Config_split versión: drupal/config_split

1. Create an example base recipe, name split_base with weight 1. Storage type = Folder.
2. Activate the recipe through the settings or through the interface.
3. Perform the drush deploy.
4. Create a new content type or make a change to an existing configuration.
5. Add the name of the modified configuration into the PARTIAL SPLIT section of the split configuration in /admin/config/development/configuration/config-split/de_mb/edit
6. Export the configurations.

"So far everything is fine, the marked configuration is exported correctly in the split_base"

7. Create another new recipe with weight 0. For example. my_custom_split. The storage also Folder.
8. Activate this new recipe through the settings. "This does not need to be active all the time, for the example we assume that we need it for a specific country."
9. Import the configurations.
10. Go to /admin/config/development/configuration/config-split, verify that the base recipe is active and that the my_custom_split recipe is also active.
11. Recreate a new change in the same configuration modified in step 4.
12. Go to the recipe configuration my_custom_split, and in the PARTIAL SPLIT section add the modified configuration.
13. Carry out an export of the configurations.

"It is observed that the modified configurations are deleted from the previous active split". In this case, it should only be modified in the split with weight 0. That is, the active split with the lowest weight, which in the end was the one that placed the configuration in Drupal.
The base split should not be changed as it is needed as a base for other splits.

The Stackable option does not work in these cases where the same configuration is found in several active splits at the same time.

Proposed resolution

Before making changes to any configuration, if it is an update, it must be validated that the configuration exists in the current split and that it was the last one placed in the storage.

Remaining tasks

User interface changes

API changes

Data model changes