So I still disagree with you, but my position is softening. I'd rather
we have a clearly-defined and understood set of criteria that I
disagree with in some places than to try to make every criterion match
my preferences. :-) So while I disagree, I'm happy to move forward
with this.
Hmm, let's try something different first. I'll provide a list of scenarios below, and I'd like everyone participating in this discussion to respond whether they think that scenario should be blocking or non-blocking (for Final), and ideally why. Perhaps we can distill some reasonable requirements if we don't talk about it abstractly or with dnf-like comparisons, but with actual examples.
Scenario 1:
User clicks Install on pkg A. She waits until that is done. Pkg A gets installed correctly. Then she clicks Install on pkg B. That returns an error. After closing and re-opening the package manager, pkg B can be installed. (In other words, only one operation can be performed, and then the manager needs to get restarted).
Scenario 2:
User clicks Install on pkg A. She waits until
that is done. Pkg A gets installed correctly. Then she clicks Remove on
pkg A. That returns an error. After closing and re-opening the package
manager, pkg A can be removed. (This problem only affects two subsequent operations on the same package. Performing multiple operations on distinct packages works fine).
Scenario 3:
User clicks Install on pkg A. Before that is finished, she navigates the interface elsewhere. E.g. seeing the home screen, searching for something, showing the installed apps, showing the updates, etc. Because of this interaction, pkg A installation process is incorrectly aborted (cancelled), i.e. it doesn't get installed. It's a bug, not a design decision. The system is in a consistent state, internal databases are valid.
Scenario 4:
User clicks Install on pkg A. Before that is
finished, she clicks Install on pkg B. Because of this interaction, pkg A installation process
is incorrectly aborted (cancelled), i.e. it doesn't get installed, and pkg B installation is started (and finished correctly). It's a bug, not a design decision.
The system is in a consistent state, internal databases are valid.
Scenario 5:
User clicks Install on pkg A. Before that is
finished, she clicks Install on pkg B. A cryptic error shows up (the user doesn't understand it), e.g. "installation constraint failed: failed to acquire a lock: pkg B". It's a bug, not a design decision. Repeating that action only shows the error again. Pkg A is eventually installed OK, but pkg B installation wasn't even started. Once pkg A is installed, pkg B installation can be started and finished OK.
Scenario 6:
User clicks Install on pkg A. Before that is
finished, she clicks Install on pkg B. An understandable dialog pops up: "Please wait until pkg A installation is finished". Once pkg A is installed, pkg B installation can be started.
Scenario 7:
User clicks Install on pkg A. Before that is finished, she performs a different valid action. That can be navigating to a different screen, or clicking Install on pkg B (the particular action is not important in this scenario). That second action triggers a bug and pkg A installation is incorrectly aborted in a non-clean manner. The system ends up in an *inconsistent* state, i.e. internal databases (like the rpmdb or dnfdb) are damaged. No further package operations (installations/removals/updates) are possible, everything results in a cryptic error. Rebooting the system doesn't help.