(long post ahead)

For those affected by the libsailfishapp storage location change, some explanations (this might be helpful for developers to fix their apps and/or for users to better understand why the breakage happened):

First, the commit that changed default behavior is 3febb7a22 in libsailfishapp.

What this does is set the application name and organization name (and organization domain). For developers that set the application name and organization name manually, this change didn't affect anything. Previously, in most cases, the application name was set to "$APPNAME" (harbour-...) and the organization name was empty. After the change, both organization name and application name are set to $APPNAME (harbour-...).

Now, we want to align with Desktop Linux and upstream Qt API as much as possible where it makes sense - this eases the porting effort required for cross-platform developers. For Desktop Linux alignment, the XDG Base Directory Specification is the way to go. For upstream Qt API, the relevant APIs are QStandardPaths, QSettings and Qt Quick Local Storage.

• QStandardPaths: It's already XDG-conformant, and also appends organization and application name to the path. Organization name only when non-empty.
  
• QSettings: It also uses XDG, and uses both the organization name and the application name (QSettings implementation).
  
• QtQuick Local Storage: This uses QQmlEngine::offlineStoragePath() that uses QStandardPaths::DataLocation + "QML" + OfflineStorage".

Because Qt has this notion of "organization" and "application", and because application developers that develop cross-platform application and might have a good reason to use "setApplicationName()" to set the name of their application to something not equal to $APPNAME (harbour-...), it was decided to use the organization name facility of Qt to place all files into $APPNAME (harbour-...) below the configuration directories (as is required by Harbour rules). When the developer doesn't set the application name manually, it will default to $APPNAME (harbour-...) - as has already been the case before. Also, this is important for pure QML (without C++ code, i.e. using "sailfish-qml" launcher) applications that are boosted, as otherwise files might end up in some strange mapplauncherd/booster directory, which isn't at all what you would expect (the directory name would be random at every invocation).

• How do I fix my application to use the right path? For a quick fix if you want your users to continue using your app, you can set the organization name to the empty string, which makes the behavior just like before the update. Please note that if you are using any Qt-based third party libraries, you might have to make sure they are calculating their paths correctly. If you make this change, please note that users might have installed your application after updating to 1.0.3.8, so add some additional code to move files from the new (with organization name set) path to the old one. Alternatively, you can move files from the old path to the new path on application startup if the old path exists and the new path doesn't.
• How do I (as a user) make sure old application data is accessible to the application after the update? The easiest way is probably to create a symlink named "$APPNAME" pointing to "." in ~/.config/$APPNAME, e.g. "ln -sf . ~/.config/$APPNAME/$APPNAME" - this will work with both the old and the new system.
• Why can't we just hardcode /home/nemo/.config/MyCoolApp and be done with it? In the future, there might be multiple users, you might have a per-TOH profile (so you can e.g. have your RSS reader show different content depending whether you have the work TOH or the party TOH on) and there might be additional sandboxing measures (so app A can't access app B's users data without app B allowing that). Also, making sure that these paths are predictable (=the system can derive from the $APPNAME the storage location of data/config/cache files) will make sure that your application data can be backed up and restored by the backup application, and that the user will at one point be able to see per-app disk usage. These are just ideas, and obviously not implemented yet, but making developers aware that they should use XDG properly and not depend on some assumptions will make new platform features easier down the road for which the application developers will not have to add Sailfish-specific code (e.g. backup app integration, clearing data on package uninstall, etc..).

Too bad this caused breakage for some users and some apps, but hopefully the apps will be fixed. In general, I think it's better to cause minor breakage in the beta phase of the OS to make sure the architecture is better down the road (and enables nice features like some of the ideas mentioned above) than to either carry along bad design decisions and/or spend time (not only implementing, but also testing all the available Harbour apps [on both the old version and then the new version] - while still missing apps that are widely used but not available on Harbour) on adding special-casing code for applications that haven't set their data paths manually.

There shouldn't be any other breakage in this area in the upcoming updates, and such breakages should definitely not happen anymore once the beta phase is over.