Thanks. If/when I get the time I'll read over it and contribute my thoughts there as well.

I agree that the default mindset should be 'fix bugs if you want to be allowed into stable repo', but I contend that at some point, the advantages of having the software outweigh the bugs that still linger. (An instance of that, to me, is that libre software with a few very minor corner case bugs is still a win over a hypothetically non-buggy closed one).

I spend a lot of time looking into computer security, and I must say: that's not adding any security.

I welcome you to explore how most big Linux distros manage their package distribution: You will find that for the most part, system packages coexist in the same repositories as completely-fluff packages - when they do segregate repositories its for organizational purposes (stability of updates expected in each repo, or Debian free/contrib/non-free segregated-on-principle repos), not security purposes.

Maybe this will explain better:
0. When apt-get downloads packages and (through dpkg) installs them, it runs as root: therefore, ANY package installed from ANY enabled repository has the SAME unbridled power/privilege on your system: ability to run arbitrary commands in the install and removal scripts as root.
1. Because of #0: Security in a repository is ensured by having the proper controls in place on what is promoted there, to keep bad/malicious software from having good chances to get into the repo, and the level of dilligence must be the same for all repos.
2. You have to understand: The segregation we have between "system" packages and the other packages, between the repos, and in how HAM handles the packages, is not inherent to the package management system. The underlying apt/dpkg stack is operating under the principles of points #0 and #1.
3. Because of #0 and #2: there is no security benefit to having separate repositories the way that we have them: the least-secure repo you use to install/update software dictates how secure your entire device is.
4. Between #2 and #3 we can conclude that: either we are confident all of our 'default' repos (incl. extras) are secure, in which case we can put system packages in any of them, or they are not secure, in which case we have a problem which is not in any way fixed by keeping some packages in another reposity.

In short, in the current way, packages in the extras repos CAN nuke and usurp and replace packages in the (C)SSU repos as is - if they want to do so maliciously, that's not a problem. But certain legitimate uses, as described in my last post, are made more difficult.

Now, as for HAM using it, maybe that's good, maybe not. I admit I don't know HAM's nuances, because I stopped using HAM within the first months of owning an N900 back in 2010 and never looked back. I used FAM for a while, then just gradually transitioned to directly using apt-get.

But from what I've heard I am not convinced that any HAM's deviations from how package managers work in the 'upstream' distros like Debian is how we should do things. I don't know of any deviation that I actually agree with off the top of my head.

For example, in the thread you link you discuss FAM's autoremove-by-default not being the best idea. I agree, but the only way it would actually break things is if packages were already buggy in their packaging (e.g. package A depended on package B but didn't declare it in its Depends field, then broke when package B was autoremoved, or maybe package C's prerm script deleted some file actually belonging to package D). If some of HAM's similarly non-standard behaviors allow badly-packaged packages to go unnoticed on a system where the user only uses HAM to manage packages, then that itself is a problem too.

Even without that though, I don't see what is wrong/missing in the standard apt/dpkg stack. I understand user-friendly/anti-stupid decisions like hiding system packages and actions like auto-remove behind some UI element (whether that be checkboxes or an 'advanced' menu or different views for different package categories, one of which is 'all', or whatever). But as far as the package management itself goes, the only differences I hear/know about, are ones that seemingly made sense for Nokia's goals of maintaining our phones are commercial product, but which don't seem to me to be best choices for a more general perspective of just having a nice distro for our phones.