Do not completely split items depending on patched ones

I had to read the issue summary and the patch (and the code around it) a couple of times to understand what is going on. And I think I understand what is happening.
But in order for future me to be able to maintain it I think it would be good to have an explicit test covering the scenario.

Because I think there is a mistake in the issue summary. And maybe there is a bug in core or core does re-evaluates the list like this patch does?

So first a correction: The entities which have their config patched are the ones calculated by manager->getConfigEntitiesToChangeOnDependencyRemoval as "update". The ones marked as "delete" are always completely split.

And just to test if core does it correctly, in your setup if you uninstall the module you split (via the UI) doesn't it also say your group roles will be deleted? and if you go ahead and do the uninstallation does it actually delete them?

I am not against your proposed change here, but I worry a bit that it creates another edge case when a config depends on another config that depends "optionally" on the module being split, but *also* directly on the module. But maybe I am overthinking it.

The part that bothers me though is that getConfigEntitiesToChangeOnDependencyRemoval is supposed to do the heavy lifting. It loops and updates the dependency graph etc. So if that list is not correct then I am inclined to say it is a core bug.
The idea with the patches is that you can split off some config and the result is as if the module was not installed. And so to get there we have to simulate the module being uninstalled (without it actually being uninstalled). So if core returns your group role to be deleted, but then doesn't delete it because it re-calculates the dependencies when doing the uninstallation then I guess we also have to re-evaluate.

Does that make sense?