Thanks,
@mrploppy, for pointing me in that direction. It caused me to "discover" something even more interesting, which enabled security updates without patching!
I found the replaceRecovery script, and curious about what it was working with, also found in SecUpd the package file EmbeddedOSFirmware.pkg, containing RecoveryHDMeta.dmg, which contained four files: AppleDiagnostics.chunklist, AppleDiagnostics.dmg, BaseSystem.chunklist, BaseSystem.dmg. I recognized those files from the root of the @dosdude Installer, and wondered if replacing them would make the Installer create the "new" Recovery, so I tried it, installing a "very patched" 10.13.6 to an external drive.
It worked! The regular OS files were timestamped in late July 2018, consistent with the 10.13.6 release, but the recovery files were timestamped late November 2018, consistent with the 2018-003 release. I had also patched replaceRecovery as
@mrploppy did in the 2018-003 SecUpd package, so I wasn't too surprised when that installed without errors. But then I checked the install log, and *was* surprised to find that replaceRecovery wasn't even called!
So using the 2018-003 Recovery files on the @dosdude Installer appeared to prevent any SecUpd Recovery problems! I tested that by repeating the "very patched" install, but then using "softwareupdate -i -a" to use the "pure" SecUpd 2018-003, no patching. That worked, no errors!
Now the question is why the Recovery install works with the @dosdude Installer, but not the SecUpd. That question is for someone more knowledgeable than me.
I suppose there may be further Recovery update issues when SecUpd 2019-004 comes out, but at least we have
@mrploppy's replaceRecovery patch to bypass that.
I think it's time to update to High Sierra. Good thing tomorrow's a holiday.