In terms of 'future', it seems to me that this forum would benefit from further exploration of 'better' package management since quality of package management is fundamental to distro quality in practice.
As we most all know, there are currently several approaches to package management, the main two approaches being:
1. distro-specific package manager such as Puppy Package Managers like PPM and pkg, Debian-based dpkg/apt, pacman, Void Linux xbps and so on.at
2. Portable package formats, some of which include some form of containerisation and some, such as FlatPak, able to share some dependencies. Major examples of these being FlatPak, Snap, and AppImage though this forum also advocates a simpler 'portable app' sfs-addon-based design which tends to be less disk-storage hungry since often works on the basis that some libs are provided in standard shared lib form by the underlying distro filesystem.
However... if you really need to 'rely on' a portable app solution for say your business, a choice between FlatPak, Snap, AppImage (or alternative containerised possibilities such as Docker, Podman based app release mechanisms) appears, to me, pretty much essential despite the usefulness of home-grown solution for less critical Linux distro usage.
Since my family does have a small business operation some, though not all, of my own distro dev thoughts are influenced by what I need for that. Currently I use a number of AppImages, but avoid both Snap and FlatPak. However, I get the feeling that AppImage is an overly simplified mechanism that doesn't entirely address the real issue of making business distro maintenance as inexpensive (in every sense) as possible. So right now I'm deciding whether to prefer FlatPak or Snap; I'm tending towards FlatPak because of the way it stores apps in repositories in a similar to Git way (albeit binaries) and can share dependencies between apps when some apps using same runtimes. So... it strikes me that FlatPak functionality might be able to be provideed via an addon squashed filesystem (sfs), which could then be shared between different KL/FR-based distros. Similarly, the individual user-based per-app config information is shared in specific folders by FlatPak so if these were made mountpoints (rather than duplicated data per KL/FR-based distros) then any such-design KL/FR-based distro could share (without any duplication) the same FlatPaks including configuration and cache details.
I'm not just thinking of something to-do long in the future, business-related thoughts like I have are on-going so I'm planning my new Zorin OS install (which I use in business), including new use of FlatPaks for some major apps, and thereafter I plan to mount parts of this new Zorin install in such a way (per above brief description) that I can share the FlatPak local repo with my later KL/FR-based distro dual-boot arrangements.
Some just write off the use of Snap, FlatPak, AppImage, Docker/Podman container solutions and so on, but really such systems are not being created to 'take over' control of Linux, but rather they are attempted solutions to the genuine issues of reliable, maintainable, less-resource-intensive (particularly human labour/tech support), package management issues that complex Linux system use and management/maintenance involves.
Oh, I should mention, when I use Linux (Zorin currently) for business I log in as normal user and, actually, I do think that nowadays that is the best approach to using Linux (i.e. an idea not popular on this forum). However, when I develop a FirstRib-based distro I generally always arrange for it to be able to boot to desktop as root user, but, via a menu click or two, be able instead to login as normal user to desktop. I do prefer a root user login desktop for admin work, but am perfectly happy to login as normal user and simply set up file access permissions for that normal user to wherever I want to store files and so on. Having to be root user to access files is just bad organisation in my opinion - but main thing is that many apps nowadays simply do not happily run as root user(!) so I personally feel no need to fight that reality, since trying to fight it becomes far too time-consuming and limits actual other development work that would be a better use of dev time IMO.
EDIT: NOTE: https://www.apertis.org/architecture/flatpak-overview/
"...for storage-constrained devices, a customized runtime can be built that includes just the common libraries needed by its typical applications. This will avoid much of the unneeded “bloat” resulting from using a more generic runtime.
However, there is a trick to minimizing disk usage, which is that Flatpak will unconditionally de-duplicate all files from installed runtimes and applications. This means that, if two different runtimes or applications have the exact same files inside, only one copy of the files is stored on disk."
"...because Flatpaks use a different version of their libraries than the host system, the library memory will not be shared with the host. Despite this, Flatpaks still share the libraries in RAM with each other, as the kernel only ever considers if the same library is being loaded twice, regardless of which application is loading it. In other words, multiple Flatpak applications using the exact same library version will have it shared in memory, but they will not share it with any applications using that library on the host system."
However, the negative of the likes of FlatPak might be well-expressed here: https://ludocode.com/blog/flatpak-is-not-the-future
Hmmm... thus far to me AppImages is in practice still 'winning' for me (outside of using distro's own package manager); AppImages end to be much smaller than FlatPak solutions, but I guess that size-differential would drastically change if I did indeed employ LOTS of FlatPaks that had common runtimes. However, AppImages need certain core system libs on underlying system (i.e. excluded from AppImage) so do not it seems allow for newer libc for example to be included in AppImage).