Your questions were specifically about Flatpak but since #AppImage
came up in the discussion I will try to answer them for AppImage since it is the system I am most familiar with. Apologies if this will take away a couple of minutes of LED blinking fun.
If you remember "Live systems", think of AppImages as "Live apps".
An AppImage is an ISO that contains an application and all the components it needs to run (e.g., libraries, icons, translations etc.) which cannot be expected to be part of the base system. There is a little executable ELF header embedded at the beginning of the ISO that loop-mounts the AppImage using FUSE and executes the payload app contained therein. Very common libraries that can be expected to be part of each target system are not bundled, less common libraries (yes, I mean you, Qt) are. By convention, an AppImage is supposed to have no other dependencies than the base system. The result is that AppImages are loosely coupled to the system, and that you can match and mix distributions and AppImages. AppImages are coupled with the OS as loosely as possible - one file equals one app, which makes it easy to "manage" apps by hand.
An AppImage also contains information on how to update "itself", i.e., where to check for new versions and download updates from. There is a binary delta updater that allows you to update from any given version by downloading only the bytes that actually have changed between the two versions. All of this is deliberately designed not to need any central infrastructure, but to enable upstrem projects to create and host the AppImages themselves.
With that, let's to your questions:1) does it allow for first-class integration across applications, or does it result in app A not working with app B because they both depend on library C but different versions and as a flatpack you cant change that, and so no app<->app or app<->platform integrationfor you.
There are optional sandboxes that can be used with AppImage, but per se I can't see anything that would be preventing apps from working with each other or the system, even in case they bundle e.g., different versions of Qt.2) does it allow build-one-deploy-on-all(-conforming)-Linux-OSes
Yes. Plus you (as an application author) can decide which systems you are targeting. Krita, Subsurface, and Scribus are currently targeting CentOS 6 and newer with their AppImages.3) is it trivial to make flatpacks (tooling, tooling, tooling)
For AppImage, the main work is to compile a binary on an "old enough" (in the above example: CentOS 6) base system. Once you have the binaries for a simple app, then it is trivial to bundle them as an AppImage (a bash script that uses some functions from a sourced script). See an example here: https://github.com/probonopd/AppImages/blob/master/recipes/wxhexeditor/Recipe
For a more complex app like KDevelop which uses plugins and calls other apps a bit more work is needed, but again a bash script will do.4) is it trivial to install and manage flatpacks, both for the single user case and the managed deployment case'
Unlike Snap Packages and Flatpak, AppImage has spfcifically been designed so that no special support from the base system is required (apart from FUSE being available, which it almost always is). The user downloads the AppImage, sets the executable bit, and can run the application. When the AppImage is executed, it loop-mounts itself using FUSE and executes the payload app. This works today - try it on your favorite desktop distribution. For some users, setting the executable bit is extra hassle; optional desktop integration (mime type association) can eliminate the need for this step.5) does its sandboxing actually work
I am aware of at least 2 different sandboxes that can run AppImages, namely Bubblewrap (the same sandbox that powers Flatpak) and Firejail. What I can say is that they "work" in the sense that I can use them to prevent an app from doing rm -rf $HOME. I don't know whether they are really bulletproof vs. malicious attackers, and I would not run applications from entirely unknown or untrusted sources no matter what promises the sandbox makes. I do trust krita.org
as a software source though.6) how many Linux OSes support it as a first-class citizen (not a weekend-drive-by-hack-to-get-it-working, nor a downstream-maintained-solution)
AppImages are known to work on most if not all common desktop distributions. Again, they are specifically designed not to need special support from the base system (altough such support may optionally be provided, e.g., to achieve sandboxing, closer desktop integration etc.).Then on top of that there needs to be a distribution mechanism that is sensible, e.g.:1) has the concept of publisher identity
I think that AppImage has the stongest concept of publisher identity among all solutions being discussed, because users can download AppImages from the upstream project download pages. It is best practice to sign The AppImages with GPG. A downloader/updater could be written that would verify the signature with a public key on the upstream application download page automatically.2) provides a single entry point for delivery to the distribution mechanism (or "app store" if you prefer); that may still end up going to/through a distributed system, but having a single point of delivery is critical
AppStream provides a tag for bundles, which can be used to make AppImages discoverable by software centers like GNOME Software and KDE Discover. An increasing number of upstream projects already provide AppStream data which is the basis for distributions' metadata collections; so it should be easy for those projects to get the AppImage information in. Plus, having a download on the project's download page is essential, as downloading something from the application author's website is still the dominant model on desktop platforms that have actual market share, despite all the efforts to introduce App Stores.3) provides mechanism to monetize and get engagement statistics (e.g. download counts broken down by various criterion)
Since upstream projects can host their own AppImages, they can track downloads in any way they choose to.
In summary, AppImage is a lightweigt transport mechanism and set of conventions for bundling software that empower usptream application authors to do what they do for the other two desktop platforms - provide binary downloads directly to their end users and have full control over the end-to-end experience.