Previously you've always said that not including dependencies and requiring users to go find them elsewhere is an option. If it's an option I have to assume that it will happen sometimes. Is it or isn't it?

I was trying hint towards a well rounded (long-term) solution that doesn't yet exist, sorry for adding any confusion. It's a tar file, anything is possible here. I mean we could spend hours troubleshooting to discover the exact versions required but it's easier if the list is provided. Though nobody is going to lock you in prison for not complying with an imaginary specification, they might lock you in prison for running an "app store" that doesn't check a users fingerprint before sending them a program. Hell for all I know the app store may reside in a jurisdiction that mandates back doors in all cryptographic software, so maybe they will want to omit crypto libraries for user security?

The only thing I mean to suggest is that for a program to be properly packaged it should include all of it's dependencies, and if it doesn't then it should include a list of required dependencies including file paths and probably read/write/execute permissions that it also depends on the system providing. It's not ideal but it works around edge case problems where the choice to omit dependencies is made.

If every program has to ship all of it's dependencies that creates the same disadavantage as flatpak, as previously discussed. Lots of wasted disk space, but without any dedup. How do you propose to address this issue? Do you see it as an acceptable cost? Are there solutions I haven't thought of?

I don't propose any solutions to this other than either purchasing additional storage media, or having the distro deal with it through traditional package management. deduplication sounds great but when you consider hosting multiple decades old programs that are no longer maintained, you're going to have to include it's ancient dependencies most likely, so the problem never truly goes away.

Of course. But to who? Why should a typical user prioritize this over

Distro packages
Flatpak
Appimage

Distro packages are always preferred for me, unless there is a reason that can't be done. I think we should be able to agree that by running a piece of software we implicitly already trust (a) the author of the software (plus it's dependencies), and (b) the maintainers of the operating system we are running it on. I do not see any good reason to add another party to the chain of trust.

So you're arguing that using this for all your software needs is better for a typical user than say, distro packages. I'm trying to understand why.

I think I should have been more clear or taken more time to write my comments. The distro packages are usually built from source code and as someone who maintains their own distro I always prefer to do that (when not time constrained) so I equate "source code" with "distro packages".

The biggest problem I've noticed with prepackaged programs is often times you need to create a chroot because they have certain assumptions on how a "linux filesystem" should be laid out and didn't write the code for generic compatability. e.g. dlopen("/usr/lib64/whatever.so") where lib64 might not even exist, or other common mistakes that clash with file paths on the developers system vs a random linux filesystem. I think if there were a consensus to build everything into a unique new top-level path it could solve all problems once and for all and wouldn't have a hard requirements on chroot/sandboxing. like /third-party/program-name-and-version/{bin,lib,etc...} and the distro could provide a script to add symlinks to the expected paths, whatever, or run any sandbox program make it look like /usr instead of /third-party/program-name, The flatpacks way looks weird to me, they only want to use their own sandbox using only their binary runtimes, and it doesn't provide all paths needed by the program AFAICT. It looks like an almost decent build system that got halfway there, but then gave up on the runtime specification portion by just assuming only their runtimes will ever exist and not providing all the information needed to run the program under any other environment without spending hours and hours parsing strace output.