Thank you for your notes and help in tracking this down.
In order to fix this within WP-Juicebox, I'd need to fetch the corresponding thumbnail URL for each individual image rather than hardcoding "thumbs_" as a prefix for each thumbnail (which NextGen Gallery always used to do until v3.21) and then appending the image filename.
This sounds simple enough until I discovered that there is no thumbnail-related entry in the individual NextGEN image properties.
I could fetch the global value for NextGEN's "Use dashes instead of underscores when generating new image files" switch but I would just have to apply this to all images in all galleries and it would break all thumbnails created if/when the switch was in one position or the other (just like the current status when using dashes). As far as I can tell, there's no way to programmatically determine which galleries were created with the switch in any particular position. In fact, it's entirely possible that a single gallery could have thumbnails with both underscores and dashes (for example, if you were to upload a few images to a gallery with the switch set to 'Underscores' and then upload a few more images afterwards with the switch set to 'Dashes'). I'd really need to determine the corresponding thumbnail URL for each individual image and this does not seem to be possible.
I think all I can do is either:
(1) Feed WP-Juicebox the full-sized NextGEN images to be used as the Juicebox gallery's thumbnails and have Juicebox dynamically resize them when the gallery is viewed.
... or:
(2) Give the WP-Juicebox user the option to set the NextGen separator to either 'Underscore' or 'Dash' on a per gallery basis (in each WP-Juicebox gallery settings window) and trust that the NextGen user does not have a gallery which uses both. At least this will use the dedicated NextGEN thumbnails as the Juicebox thumbnails.
I'll think it over for the next version of WP-Juicebox.
In the meantime, I'm glad that you've found the cause of your problem and found a suitable workaround.
Thanks, again, for taking the time to document this issue. It's most appreciated.