How to handle CommonAppData aka All Users AppData aka C:\ProgramData?

Since the folders won't exist prior to first run, I recommend not including them in DefaultData, and including the necessary folder moves in the DirectoriesMove section.

That should be reworded.

In PrePrimary, FilesMove moves files from the Portable Data directory to local locations, backing up local versions, and DirectoriesMove moves directories (including files & subdirectories) to local locations, backing up local versions, unless the key is named -, in which case it only backs up the local version, as there's no Portable version to move.
In PostPrimary, FilesMove moves files from their local locations to the Portable Data directory, restoring the local versions to their original place, and DirectoriesMove moves directories from their local locations to the Portable Data directory, unless the key is -, in which case it discards them, in either case, it restores the local versions to their locations.

Currently PrePrimary calls FilesMove first, then DirectoriesMove, and PostPrimary calls DirectoriesMove first, then FilesMove. I'm suggesting we switch this so that PrePrimary calls DirectoriesMove first, then FilesMove, and PostPrimary calls FilesMove first, then DirectoriesMove.

Now... I'm having some difficulty keeping track of your examples, as you've written them rather sloppily, and I'm not sure why you have so many, but this is my best attempt at interpreting them:

[FilesMove]
filename.ext=%AppData%\a\b

[DirectoriesMove]
-=%AppData%\a\b\c

In this case, there is no issue no matter whether FilesMove or DirectoriesMove happens first, as they are simply next to each other, and won't be bothered by each other. The local version of filename.ext will be backed up, the Portable version will be moved appropriately, and the local version will be restored, likewise, the local version of %AppData%\a\b\c will be backed up, the Portable version will be used & discarded as specified, and the local version will be restored. No conflicts

[FilesMove]
filename.ext=%AppData%\a\b

[DirectoriesMove]
-=%AppData%\a

In this case, it currently causes the %AppData%\a directory and its contents to be discarded before %AppData%\a\b\filename.ext gets moved back, causing the exact issue mnedo is having. If however, FilesMove and DirectoriesMove were switched, as I suggest, then %AppData%\a\b\filename.ext would be moved into the Portable Data directory, after which %AppData%\a would discarded, meaning that filename.ext would not be lost.

[FilesMove]
filename.ext=%AppData%\a

[DirectoriesMove]
-=%AppData%\a\b

Again, these will not interfere with each other whether the FilesMove & DirectoriesMove are switched or not.

[FilesMove]
filename.ext=%AppData%\a\b\c

[DirectoriesMove]
-=%AppData%\a\b

And again we're back to experiencing mnedo's current issue when using the current configuration, and no issue if they are switched.

Glad I could help.

When you say that "the app now works exactly as expected", does it backup and restore the local version of the directory, as an official app would need to do, or does it end up erasing the local data if it was present, as I believe DirectoriesCleanupForce is designed to do?

As to whether or not the "potential fix" I've posted will be used in a future official release of PAL... If it doesn't break anything, it most likely will. If it fixes this issue but breaks something else, it probably won't unless we can fix whatever that issue is.