The current change detection algorithm uses the object name as the unique identifier and if the object exists in both the new and the old configuration, it is assumed to be the same object. This algorithm lacks the capability to detect the case where the object was destroyed and recreated with a different module or a different set of parameters that can only be defined during module creation.
Detecting a change in the module type is easier as it requires comparing only a handful of fields in fixed locations. In practice this consists of the module, router, and authenticator parameters of each object. Detecting changes in parameters that can't be modified at runtime are harder as it requires inspecting the parameters of the module and comparing the parameter values.
An alternative approach would be to recreate any object that fails to be altered successfully. This would effectively result in the same outcome but with less code involved. This method is less refined and would produce more error messages that the first one if both the alteration and the recreation would fail. It would also necessitate re-adjustment of object relationships whenever objects were recreated. Due to the limitations of this approach, improving the algorithm to compare more than the object name is likely to be the better choice.