The way I look at it, this commit would introduce a potential problem (if suddenly QStandardPaths starts to behave differently) and wouldn't fix any existing problem. Which doesn't seem to be much of an improvement 😐

Well, this is not entirely true. Hardcoding paths is often error-prone, and if QStandardPaths starts to behave differently, this would only mean that it is correct (to respect new QStandardPaths behavior). However, Qt is unlikely to do it (because this interface is primarily intended to unify standard file path access across all platforms that Qt supports).

The .local/share/ path may not be as useful of a change, but the ~/Documents directory can be named e.g. in Polish ~/Dokumenty. This is in line with freedesktop.org specification that Sailfish aims to implement. Many desktop distributions (Fedora, Ubuntu, Manjaro etc.) do exactly this during installation.

Please keep in mind the /home/nemo -> multiuser (defaulting to /home/defaultuser) change that happened quite recently.
While this commit currently changes nothing in behavior for most users, it will make the codebase cleaner and probably help @ehdis who reported #9 (and me if I decide to change the directory name).

By the way, would you consider moving the foil.key file to some location Documents too? This would help implement SailJail (for this app at least): the only thing that is unfeasible with sandboxing is accessing the foil.key under currently used path, I tested it and every other function of the app works fine, see branch sailjail on my fork. I see that FoilNotes must be unsanboxed, because it accesses Notes' private data, but FoilPics could use sandbox support too. I understand your point that your apps need to be trusted anyway, but this is not about trust, but out-of-the box Jolla store accessibility of the apps, because you have done great job and the apps are the best. :-)

Generally, I'm not planning to move anything for two reasons.

One is interoperability. The same key file is shared with other foil apps (1, 2).

The second one is the data migration (i.e. when you install new version on top of the existing installation). Even if migration is done properly, downgrades would still be broken.

I need a really really really good reason to justify the move.

The change you have proposed doesn't immediately break anything because currently QStandardPaths returns the same paths that are now hardcoded. In the future, two things can happen:

1. QStandardPaths doesn't change its behavior. In that case your change is a noop - useless but harmless.
2. QStandardPaths starts returning different paths depending on the locale or whatever. In that case your change breaks the app because it won't be able to find the files.

In either case I don't see any benefits, and the second case is a potential problem.