[KevinH]

Upon examining the code further, the other reason we moved to always using the BulkRename routine was actually correctness (now that I can read the code). The old version of Rename used to assume that manifest ids are only used in the spine, when in fact under epub3 they can be used in manifest fallback ids for non-primary resource types, and in media-overlay ids for smil files as well as some external namespace metadata types can refer to manifest ids as well.

So the old routine by changing the unique id of a file in the manifest and its idref in the spine could end up breaking smil media-overlays and fallback resource manifest ids.

It is just safer to not change the manifest ids when renaming the file itself as it is technically not needed and really is only a "cosmetic" change seen only by the epub developer, never the end user, that can really break things if you are not careful.

To change just one manifest id, would require walking the entire spine and then walking the entire manifest itself looking at fallback ids, media-overlay ids, and then walking all the metadata and trying to see if any reference that specific manifest id.

When dealing with thousands of files being auto renamed/renumbered, the routine would be end up being quadratic in time parsing and reparsing the opf to fix each tag thousands of times in a loop.

I am not sure going back to the old behaviour makes much sense, even just for single renames.

The old routine was passable for old epub 2 but under epub3 it was both a performance and correctness bug waiting to happen.

Correctness and faster performance are the reasons I moved to the Bulk Resource Rename approach. Adding back an incorrect approach, is probably not the best idea.