When you moved your old data you also moved your old config files which did not match the new hardware – conflict occurred.
Deleting the old configs allowed the app to create new configs and eliminated the conflicts.
The issue is really that a user has config files for each app they normally use that is tailored to match both the app and the hardware. When the hardware changes then it is up to the user to resolve the potential problems that may be related.
There is no app I am aware of that can make the changes of this type automatically since the data in the users home directory is mostly static once the configs are created. Only the app is allowed to change the static config data it creates.
The point is, when I plug in a new sound card, or remove a sound card (nowadays these are most often live USB events) the apps react.
When this happens offline (e.g. somebody changes their soundcard while the PC is off), the software does not recognize that???
Plus, ~/.local/state does not exactly sound like a config file to me. Worse, it’s not “grandma” compatible (Basically, there is no way to trigger that configuration change) without guessing and deleting random files in $HOME and hopping, to nuke the correct one, and not the rest of my KDE desktop setup.
(by the way, somebody should nuke the joksters that think it’s cool to stuff cache files into $XDG_CONFIG_HOME, e.g. Chrome, Slack, IPFS, …), which makes searching around ~/.config even harder.
While I agree that automatic changes would be nice, it also is reality that only each app can tell if there is something wrong. Having each app capable of detecting hardware changes seems unrealistic at best and potentially a nightmare at worst. Remember that the app only has to be aware of the drivers it talks to. If the driver changes the app does not necessarily know what changes were made. Maybe the device disappeared – which often happens with hardware changes – so the app has no information on what changed.
Normally this scenario only occurs when migrating to new hardware – whether it be one new device or an entire machine. Thus the user should be aware of potential problems and be able to track down changes that result.
Sure, because this is so well documented, that .local/state/wireplumber STATE directory.
Point is sound devices today are plug and play. USB & Bluetooth devices are plugged in at random times. They normally show up (I could not try out BT, as my BT was also out of order, shrug). Actually, when working normally, it actually detects dynamically things like plugged in headphones.
You are mistaking this for a case of “configuration”, this is a case of software not clearing up “state” files, it should clear up.