Although I have not found the smoking gun that caused the 7.1 system to 
hang after a partial (hung) upgrade of an application RPM.  However, I 
have found the item that was being upgraded: darktable from EPEL .   
Evidently, the latest darktable required other components.

A second observation.  I use the Mozilla suite from current stable 
production (not SL ESR) release, including Firefox, Thunderbird, and 
Seamonkey (the latter for the HTML editor integrated into the browser -- 
but I do not use Seamonkey email). When the upgrade created a new /home, 
not reusing the previous /home that was preserved untouched, the upgrade 
automagic install of firefox (ESR, of course) created a .mozilla in my 
new home directory.  Originally, I left that untouched but did a ln -s 
from my oldhome .thunderbird to my new home.  This created 
instabilities.  I solved this by:  1  in my new home directory with none 
of firefox, thunderbird, or seamonkey "open", I did mv .mozilla to 
dotmozilla and then a mv of both .mozilla and .thunderbird from my old 
home to my new home .  Things seem to be working.  Do understand that I 
do not manually modify any of these dot files; all were created and 
manipulated by the various releases (none beta, all production) of the 
Mozilla suite components that I use.  What I observed could be artifacts 
of the way the Mozilla suite maintains these files, or it could be due 
to some of the configuration being kept by Mozilla in one file and some 
in the other, requiring both to be mutually consistent.  This is just a 
word of caution.  I have not studied the current source code for the 
Mozilla suite and thus do not know the answer, only my empirical 
observations.

The subject includes "pseudo-upgrade" because what the 7.2 upgrade seems 
to require is a re-install, at least if something gets "broken" as it 
happened in my 7.1 .

Yasha Karant