The default configuration sets TestingPath for Zandronum to $HOME/Documents/doomseeker/plugins/zandronum. Typically the downloaded testing releases include an executable binary and shared data (Skulltag PK3 files), which is a bit dubious to fit in the $XDG_DOCUMENTS_DIR directory.

I expected $XDG_DOCUMENTS_DIR to be reserved for paper documents, literature at best.

The documentation link you posted says QStandardPaths::DataLocation is deprecated and returns QStandardPaths::AppLocalDataLocation.

I know the torbrowser-launcher package in Debian GNU/Linux uses it ($HOME/.local/share/torbrowser) also for binaries, but that package is "not part of Debian" because of contrib section. It's acceptable, but not maybe the best choice. .local/share is meant to be for architecture independent files, after all.

Seeing how QStandardPaths::ApplicationsLocation is not always writable and it's used differently on Windows, it's also probably not a good choice.

I think QStandardPaths::AppLocalDataLocation ($HOME/.local/share/doomseeker) is still a more sensible choice, but that's arguable. Someone else may have a better idea.

QStandardPaths::DownloadLocation or its subfolder may also be a sensible choice, excluding the generated shell script which should go to $HOME/.local/bin in my opinion. (Note, $HOME/.local/bin is not part of default $PATH.)

One caveat: Zandronum testing releases really shouldn't dump its arch-dependent binary and libs (x86 or x86_64) under one arch-independent .local/share directory, but that's out of scope for this ticket. This is partly an upstream issue of packaging too.

It struck me that there might actually be a better place for this: /opt/ on GNU/Linux globally (or $HOME/.local/opt/ for the local user as a non-standard location). /opt/ doesn't exist on OpenBSD, though.

It's still less ideal than seperating everything under .local/bin, .local/lib etc seperately, but it's not our issue to handle upstream issues. 😕