GenericConfigLocation and AppConfigLocation provides on Windows a disposable folder that is not purposed to store configuration

The documentation ( https://doc.qt.io/qt-6/qstandardpaths.html ) says that on Windows,
`GenericConfigLocation` is set to `C:/Users/<USER>/AppData/Local`, while `AppConfigLocation` is set to `C:/Users/<USER>/AppData/Local/<APPNAME>`.

This is both wrong and this leads to configuration loss. The reason why is that the `C:/Users/<USER>/AppData/Local` folder is meant to be local to the computer, and then, lost with the computer.

On the contrary, the `C:/Users/<USER>/AppData/Roaming` is meant to roam with the user.

Let's take an example of a computer network (a company, a school…), computers are replaceable, and may even not be tied to a specific user.

The “Local” folder on the contrary is local to the computer and only exists on that computer and is never shared with anything.

When an user connects to computer1 on day 1, the user's “Roaming” folder is downloaded from the server to computer1 and kept in sync with the server.

When the user connects to computer2 on day 2, the “Roaming” folder is downloaded from the server to computer2 and kept in sync with the server. If the configuration was stored in “Local” instead of “Roaming”, the configuration stored on computer1 is not accessible by computer2, the “Local” folder is empty, and the user has to recreate the configuration.

When on day 3, the IT department replaces all computers with new ones, both computer1 and computer2 are replaced by computer3 and computer4. Both “Local” configurations stored to computer1 and computer2 are thrown to a bin and there is no way to recover them.

When the user connects on computer3 on day 3, the user's “ Roaming” folder is downloaded from the server to computer3 and kept in sync from the server, the “Local” folder is empty, and the user has to recreate the configuration.

When the user connects on computer4 on day 4, the user's “Roaming” folder is downloaded from the server to computer4 and kept in sync from the server, the “Local” folder is empty, and the user has to recreate the configuration.

As the name says, the “Local” folder is not “Roaming”, and then is not meant to be kept in sync with a server, to be kept in sync with other workstations, and is not meant to be backed up.

Storing application configuration in the “Local” folder is the guarantee to lose the application configuration.

Unlike Linux  XDG `<sub>/.config</sub>` folder (application configuration) and `/.local/share` folder (antinomic name for shared-then-non-local application data), and unlike macOS `<sub>/Library/Preferences</sub>` folder (application configuration) and `/Library/Application Support` folder (application data), Windows only has the “Roaming” folder for both configuration and data, applications may chose to make subfolders themselves, but on Windows there is no parent folder for configuration and another parent folder for data. Storing application configuration in “Local” and application data in “Roaming” means the data is always backed up by the server and the configuration is always lost when the computer is replaced.

On the other hand, neither Linux and macOS has a distinction between “Local” and “Roaming” like Windows do. The features do not map between Linux XDG/macOS and Windows.

Windows applications have to store both configuration and data in the “Roaming” folder, being in the same subfolder (in the same way that on Linux XDG and macOS Local variants store in non-Local one because there is no Local folder in those systems) or not.

This bug is very old, I remember having discussed it in a KDE bug repport in 2017 at Qt 5 time:
https://bugs.kde.org/show_bug.cgi?id=382358

This bug also got discussed in that other bug report in 2018 and in 2024 as people mistakenly consider to use `AppConfigLocation` or `GenericConfigLocation` to store applications configurations, that leads to systematic configuration loss on Windows:
https://bugs.kde.org/show_bug.cgi?id=402346

I'm sorry to have failed to report it upstream, here, before.

This Qt bug makes Qt's `AppConfigLocation and `GenericConfigLocation` non-portable, requiring Qt applications to write custom code to always use the “Roaming” folder on Windows to workaround the Qt bug.

Fixing this bug may also require to implement a migration code so anytime an application sees an application configuration stored in the “Local” folder, to move it in the “Roaming” folder (with a possible symbolic link in “Local” for backward compatibility if permission is available on Windows (symbolic link creation on Windows unfortunately required an admin permission until very recently).

There is a single use case where storing some application configuration in the “Local” folder makes sense, is that if such configuration is tied to a specific computer hardware and meant to not be portable. For example this can be some application layout or a screen color profile for a screen attached to a laptop, assuming the user will never replace the computer with the same exact model (which is not true in a managed IT service). This “Local” use case is so rare this is probably why Linux XDG and macOS never bothered to implement the Local/Roaming difference, and it is probably better to not care about this use case, meaning Qt will never use the “Local” folder and then an automatic migration of configurations mistakenly stored in the “Local” folder to be moved to the “Roaming folder can be implemented without any conflict between “Local” and “Roaming” since everything would be “Roaming”, which is already assumed to be true on Linux XDG and macOS.

An application facing the very rare need to get a configuration to be specific to the computer will better hash some machine description and attach the custom configuration bits to this hash in the common “Roaming” folder, and it would work on any systems, and would even be restored if the computer is replaced with the exact same model.

The use case of a “Local” data folder is like the “Local” configuration: something local to the computer and then disposable. Most of the time this is redundant with the cache folder. Both Linux XDG and macOS have no concept of disposable local data that is not cache, and then already store all data in the non-local and non-cache folder.