Versioning packages for breaking upgrades

It's not just mistakes and incompatibilities. As you said, that's where development happen. That's where you have the chance to make breaking changes if you judge they are needed. The packager judged them needed and so he introduced them.

> Deliberately removing functionality without a very good reason, I'm not so sure that is what someone should expect. But OK, it can happen.

Your very good reasons may be my irrelevant excuses. The packager gave his reasons and it does sound like the original package had more things than Debian packages tend to bring by default. Most other packages have plenty of optional dependencies and what not.

> But when people report that e.g. they can't open their password database anymore because their is no support for hardware keys anymore and they're not taken seriously, that is not to be expected.

That may have been wrong, yeah.

> When people ask to "Put the base package back where it was and create a keepassxc-minimal" and get "that's not going to happen" as an answer, that's not to be expected. That's going to upset people.

Demands and asks are two different things. The packager offered a solution, which was a keepassxc-full. The users decided pointing to the other package was too much work, apparently.

> I don't see how it happening in unstable is an excuse. Of course it happens in unstable, that's where Debian development is done. Are users only allowed to file reports when an issue is noticed in stable?

Certainly not. You can and should file issues against unstable. But that's moving the goal post, we were arguing whether you should expect a flawless break-free experience on unstable and whether that's a fair expectation. Demanding the solution to be "keep my setup as it is" when running on unstable is what's out of place. It's the place where breakage is allowed and you opted in, you deal with some changes that require manual intervention, such as moving to keepassxc-full. If it still breaks because of bad packaging, then it's a different story.
Essentially, the difference is in the definition of bug for each case. For stable, if your current config no longer works, it is a bug. For unstable, that is simply a change that requires manual intervention, and only proper software flaws are bugs.
But in any case, when you use a distro package you check their issue tracker first, before bothering upstream. It's common sense, upstream doesn't have the same version.

> That makes no sense at all. Unstable and testing exist precisely to fix issues before shipping the next stable. We should praise people for reporting issues, not blame them because 'they should expect breakage'.

We should praise them for testing, reporting, etc. Not for demanding a change be reverted just because it breaks a stability promise that nobody made. Certainly not for bothering the wrong person.