Well that’s a dispiriting read.
Snaps may be great for maintainers, but they absolutely suck for end users. Whomever said earlier in this topic “everybody love snaps”, I don’t know in what alternate universe you’re living in. There are so many people driven off from Ubuntu at each release with snaps more and more taking over the system. The last one being Firefox, FFS. I’m still on Ubuntu 18.04 LTS on my desktop (!!!), and when comes the time to finally upgrade it next April, I’m seriously facing a dilemma. Anyway, not the debate here.
Liking PPA better is not package dogmatism (now that’s an insulting remark), it’s pragmatism from an end user POV. Everything is managed from one central place, Ubuntu’s packaging/updating system. You add the PPA to your system sources, and you’re done. AppImage and flatpak are little better than snaps in that regard.
How many times have people had problems over the years using Add-ons with the AppImage builds? Has this been solved yet, I wonder? We’ve never had such issues with the PPA package, because it is basically a system package.
I know some of the criticisms about PPAs is that it can mess up a system if system libraries are replaced. But with FreeCAD, no important system libraries (i.e. KDE, GNOME, Qt, libc and such) are affected. When the PPA replaced dependency packages with newer versions (libcoin for exemple), it very rarely affected other software.
That being said, I do understand that for a project such as FreeCAD, it’s difficult to find maintainers for each major distro. Creating a single, cross-platform package makes sense. End users don’t seem to be aware that even for such a major Linux distro as Debian (and probably others), finding package maintainers is problematic. I doubt if even 50% of the tens of thousands of packages in Debian have dedicated maintainers.
Add to that that over the years, the number of system libraries FreeCAD depends on has exploded. Thinking of the dependencies required by FEM for example.
That Debian packaging is such a complex mess does not help. Kurt did a terrific job repackaging FreeCAD, but it’s now intricately linked with the Debian source package repo. You may not have to become a Debian Science Maintainer to contribute to it (I really don’t know), but you need to push pull requests to the Salsa Git repository that hosts the Debian FreeCAD package (would PRs from a non-Debian maintainer be accepted? And if so, in a timely manner?). It effectively left sgrogan and me (the two previous FC PPA maintainers) unable to help further with the PPA.
The learning curve is steep: you need to master Git, bash scripts, patches, the whole Debian packaging toolset, etc. And deal with missing, or obsolete dependencies. Which I gather is part of the current issue.
When I was doing it, I never wanted to package for Debian, because it would have been too much for me to handle. The PPA was my sandbox, and it didn’t matter if my packages were not DFSG-compliant.
I guess what I would suggest anyone willing to give it a shot at this time: to consider taking a step back to reduce the complexity a little. I would decouple the PPA recipe from Salsa. I would migrate it back to Launchpad. Then you have full control. Either to a Git repo or a Bazaar branch. I always found Bazaar easier to deal with than Git. Create Bazaar branches for each Ubuntu release (if the dependency versions are not the same between releases). Not sure if a recipe can nest a Bazaar branch into a Git repo (FreeCAD source code), that would be something to look into.
Launchpad does have documentation on packaging.
Anyway. I hope someone comes forward, good luck to them. Otherwise, I guess I’ll have to start using AppImages when I upgrade my OS. 
