You should definitely use shadow files. I've been using them since starting with Hercules in 2009, and I can't count the number of times they've saved my ass when making changes to my z/OS 1.10 system. My shadow files use about 2Gb, the original 1.10 files come to 16Gb, and two sets fit on a DVD-RAM disk, which I produce about four times per year, but my normal backups are kept in four additional directories and I do the backups with a simple bat file:
ren shadow-4 shadowx
ren shadow-3 shadow-4
ren shadow-2 shadow-3
ren shadow-1 shadow-2
ren shadowx shadow-1
copy shadow shadow-1
And if I screw up, it's just a matter of copying shadow-1 back to shadow, obviously not making backups after making potentially system-breaking changes!
I'm carefully reading? My main concern is that some of the parameters there proposed may not be present in MVS IDECAMS version. I have to figure that out. Beyond that, the guide reads clear, comprehensive and to the point. Reminds me to a kind of 'Linux Howto' Mainframish equivalent. It covers several scenarios and use cases, including the one I'm in: redefining my Catalog to have more growing space. Very good point!
Regarding your proposed 'high level' roadmap. Sure, best bet is backup everything first! In fact I'm going to arrange a separate Tk5 as testing ground to practice all this... I think the hercules DASD shadowing feature could be helpful in this scenario in order to 'rollback' from foreseeable 'screwed up' situations (I have never used it). But I have to further read on repro... I found that it can do many things! so I fail to see the meaning and differences between roadmap steps 2 and 3 (I grasp it goes towards having VSAM stuff dumped to vanilla PS datasets).