I think we pretty much agree with where the problems that I have with Linux Desktop application management largely come from.

> * they still leave us with the same update management problems as I outlined in the Windows case

Not necessarily, there are a lot of ways to go about discovering which applications need updates and where to get them. Off the top of my head: they have a manifest file (or header) that specifies a URL for acquiring the update and the OS maintains a list of paths for every application ever launched to be checked with a single command, as well as optionally being able to search for applications to update.

> * they don't really cover everything application packages or installers are expected to be able to do, like bundle kernel modules, modify the operating system configuration, or set up runtimes for programming languages (this is why you end up with executable scripts that run as root for macOS .pkg installers)

Agreed, but I'm mostly concerned with desktop applications, if that wasn't clear. Such add-on software needs some mechanism of being easily visible to the OS, which probably necessitates something like a fixed path, but I don't think it can't still be self-contained. IIRC Slax did something with AUFS that involved self-contained objects in a special directory that were applied as overlays over the base system at boot and on-demand, which is one way to do it. I think all Haiku packages kinda work like that too.

> * AppBundles can and do have dependencies which are unmanaged

I don't think they should. Or rather, the dependencies that are not part of the base system are considered part of the application and should be contained with it and updated with it. UI toolkits, system interfaces, cryptography, networking, and other such libraries used by a large number of applications should be part of the base system. As you mentioned, part of the problem here is that Linux Desktop has never had a concrete idea of the separation between platform (base system) and application. However, Flatpak kinda does, because it has 'runtimes'. If Flatpak managed the runtimes as it does today, but allowed self-contained portable application folders to run from wherever and use said runtimes, that'd be pretty close to ideal I think.

Out of order because related:
>> * I don't really like the idea of Flatpak applications being distributed as files becoming popular, because I'd rather developers submit their apps to Flathub or somewhere similar so that they're still usable via remote management tools;

Whereas I don't like the idea of developers and users being beholden to the whims of a repo to be able to distribute and consume software conveniently. We may just have to agree to disagree on that one.

>> * and where to draw the line between the runtimes and the application is not clear, since in Flatpak, runtimes can depend on other runtimes. The more you deduplicate, the more you lose the ability to manually manage your application storage. The more AppBundle-like you make Flatpaks, the less deduplication and internal dependency management you can do.

It shouldn't be that hard to find a reasonable balance I don't think. Some duplication isn't really a problem because, as I mention elsewhere, assets are a heck of a lot bigger these days than any binary. Further, many (some would say most) "shared" libraries are only really used by a single application. There are obvious candidates for the 'base system'/'runtime' platform: UI, system interface, networking, cryptography, etc. The problem there with Linux of course is that ABI compatibility is frequently broken in some of these so you'd have to have a bunch of versions to cover everything.

> * real applications often involve multiple bundles, which is one of a few reasons that your tools again have no real uninstall capabilities (take a look at a few Homebrew Cask formulae[0] and you'll see examples of this, e.g., here[1])

See above. To reiterate: I think this is just a poor way to do things. If you have some tightly integrated set of applications they should be managed as a single unit. Think an 'MS Office' application instead of a separate Excel, Word, and Outlook.

> * it's not hugely important, but AppBundles do still result in enormous application/installer downloads, and a base macOS install takes up 2-4x the space it probably could (this is less egregious than on Windows because at least Macs come with a fairly comprehensive set of basic GUI applications)

I don't really use a modern mac and haven't since the early 2000s, but as far as I can tell from using applications in general the actual binary portion of them is usually dwarfed by things like graphics and sound assets, which isn't helped by the traditional package management system anyway. Besides, we're living in an era when people voluntarily bundle an entire goddamn web browser to handle their application's GUI. There's no way native-GUI AppBundles are worse.

> You mentioned that Windows is the desktop operating system you're currently using, so it seems Windows' application management norms must be acceptable to you.

I guess that's one way you could word it. Another one is that Windows does a lot of things wrong, and its application distribution mechanism isn't ideal, but overall the things Windows does wrong don't bother me as much as the things Linux does wrong. As I mentioned in the very first post in this thread though: Windows is rapidly become so bad that Linux might soon be the least-worst choice. When that day happens I will not be any more inclined to like the way Linux Desktop does things, I'll just finally hate Windows more.