> They can be mounted either way. The /system/ packagefs mountpoint is a kind of "overlay" in the loose sense, but it does not use the standard "overlayfs" but rather packagefs manages the "overlay" itself for a variety of reasons (both technical and practical.)

Right, magic.

> But I don't know what difference that really makes vs. AppImages.

AppImages don't pretend to be somewhere they're not. The mounting just gives the application a way to see its files. hpkgs are mounted as part of an installation step, AppImages are mounted as part of a launch step. It isn't ideal, but like I said it has to work within the limitations of Linux.

> But you seem to have no interest in actually using Haiku probably ever

This is true. I have to say, having my only interaction with the community be arguing with you has notably soured me on it, unfair to the project as that obviously is. But more than that, there's just too much magic in it for all the limitations it still has. In the far future when it has VMs, application sandboxing, and reasonable hardware acceleration it will be easier for me to accept the things I don't like about the design, but that's a long way off. A simpler system would appeal to me a lot more and make it easier to sacrifice those other things.

> a feature that one person currently wanting it

Probono also wants it, he said as much in this very article, and he is an enthusiastic user of Haiku right now.

> We (intentionally) don't collect metrics of how many actually running systems there are;

I'm not saying you should, I'm just saying you're being a bit presumptuous when you claim to speak for 95% of users, whom you've not only never polled but also can't even measure. Not to mention that such claims sound a lot like the "99% of users just want Chrome" excuses of Linux Desktop evangelists. This is why I keep saying that what you really mean is 95% of Haiku developers, the parts of the community you have frequent contact with.

> Again, your disputes are "I don't like the way it is done because X", when in fact X is not true, and that is my dispute.

X is true. hpkgs are not simple and employ "magic", they are not bundled with their dependencies, they cannot (today) work from arbitrary locations without jumping through hoops and recompiling. These are true statements. The only disagreement seems to be how much this matters.

> Uh. You have to recompile code in order to add features. If someone added support to get this from a configuration file, then you wouldn't. Not sure why you are so surprised.

I'm surprised no one thought to make it a configuration option already. It seems like such a simple thing to look at a hardcoded path and say "maybe I shouldn't hardcode this path".

> Next you are going to tell me that /dev and /proc, being "blessed paths" are "magic".

Yes and no, because you can mount devtmpfs and procfs in arbitrary paths, but also yes because too many developers hardcode their location. I'm going to go with "yes", and in an ideal system they wouldn't even exist as part of the "file" hierarchy, per-se. UNIX baggage, etc.

> If you are really saying entirely, without any limits, then you are right, we are going to hit some disagreements.

Ideally, yes. I don't see any reason that any kind of file structure need be imposed on the user. Ideally there is no "system" partition, no "/boot" as I understand it to be called in Haiku, there's just whatever volumes exist and whatever files are on them. The system was booted into ram from a single file, its interfaces are not exposed as a file hierarchy. Applications and documents go wherever the user wants them, on permanent media, removable media, network shares, whatever. There's no such thing as having to "install" anything. The system is a file, the applications are files (or folders). Boot a new version off a thumbdrive and all your applications are available because hey, they're just files and folders out there on volumes.

Because the world isn't perfect, yeah, it is unlikely to be this perfect. For one, the location of the system file will be subject to the whims of the boot mechanism. But really, that's still a far cry from "all applications must be installed on the same volume as the system or otherwise in a list of blessed paths".