Yes, if jAlbum can generate the image, that is the more robust solution.
That also means I don't have to mess with things like isDirty() and EmbeddedProperties, to avoid regenerating the "extra" slide image on every build, nor do I need to delete a folderimage.jpg that isn't needed, if the user changes the album structure.
I discovered the correct techniques by trial and error.
A familiar road.
In my exploration of the imagePath variable, I've covered several sheets of paper with little "truth tables," as I've tried to sort out the permutations and combinations. Things get really interesting when you combine Link to originals with/without Force JPEG writing and PNG's and GIF's. Truly a journey of discovery.
Yes, this is the messiest part of jAlbum. One would need a "should be" vs "is" comparison of various input and output in order to tackle it, then set up the "should be" as an extensive unit test and then rewrite that method from scratch.
Tricky to do without breaking some skins. I wonder how many skin developers have, in effect, "coded to the bugs."
In this case, a core fix wouldn't break what I'm doing in the skin. At worst, the skin would then be doing a little extra processing that wasn't needed any longer. But it wouldn't produce a broken album. I'm not as sure about some of my other skins....