Thus is the nature of updating settings. Easy mistakes to make include: * Changing a field's default value (is that even a mistake? users might perceive it tha

Thus is the nature of updating settings. Easy mistakes to make include: * Changing a field's default value (is that even a mistake? users might perceive it that way. Also, is there a difference between a field set to the default value and has never been changed vs a field explicitly set to the default value? Should you change it in the latter case? Did you even track the latter case?). * Overwriting a field's non-default value and setting it back to default. * Migrating a field and mapping the non-default value to the wrong non-default value. * Migrating a tuple of fields to another tuple of fields and getting the map wrong for an edge case subset of the input values (bonus points if that subset was thought to be an impossible state to get into). etc... The best way to avoid settings updates it to throw it all on the user. eg, Arch Linux just takes the approach: if, you update a file in /etc, the new file is just created with a special file extension and merging the new and current file is left to the user. You don't get nearly as many surprise updates, but... you spend time merging config files, which few people are willing to do.