I completely agree, the current design directly results in the fragility you described (I pushed for naming domain-specific configuration files using their immutable, system-defined domain IDs instead, but lost that argument... I think on the basis of deployer experience? I'll let Henry Nash comment further).
As a workaround, you could set the "identity:update_domain" to be more restrictive (to users that understand the impact of such a change), or disallow it completely.
I'm leaving this as Won't Fix, as the only alternative solution I can think of is introducing a new configuration option that determines whether configuration files are named using domain names or IDs, which doesn't quite seem worth it (just to provide backwards compatibility... unless someone has a better idea? if so, please change the status accordingly).
I completely agree, the current design directly results in the fragility you described (I pushed for naming domain-specific configuration files using their immutable, system-defined domain IDs instead, but lost that argument... I think on the basis of deployer experience? I'll let Henry Nash comment further).
As a workaround, you could set the "identity: update_ domain" to be more restrictive (to users that understand the impact of such a change), or disallow it completely.
I'm leaving this as Won't Fix, as the only alternative solution I can think of is introducing a new configuration option that determines whether configuration files are named using domain names or IDs, which doesn't quite seem worth it (just to provide backwards compatibility... unless someone has a better idea? if so, please change the status accordingly).