I'm glad you followed up, I had wondered what happened.
The extra bounding box vertices was fixed in 3.0.13.
Spine only loads the images that it needs to render into memory. Eg, when not playing, only the displayed images are loaded. When hiding/showing an image, the images are actually loaded and unloaded on the fly. When playing an animation, all the images that are shown during that animation are loaded so that there is no loading delay during playback. This means you can have many thousands of images and Spine will work just fine (unless you show them all in an animation and don't have enough GPU memory, which is unlikely). How many images do you have? What is an average size for these images?
Spine uses the OS provided APIs for file watching. Unfortunately it seems sometimes this doesn't work well. I've seen it stop reacting to file changes for seemingly no reason.
Interesting, so you replace images with 1x1 placeholders as a fast way to hide all the attachments so the artist can work easily?
In Spine v2, the export was not headless, meaning it actually was running a lot of GUI related code. In v3 it is headless, when possible. Data export and texture packing run in headless mode, but image or video export cannot because those use OpenGL to render images. Headless is faster and allows export to be run on computers that don't have graphics hardware, like a build server.
This means one way to workaround this issue is to include an image or video export along with your data export. Eg:
Spine -i yourProject.spine -e dataExport.json -e imageExport.json
The image export can be anything, you can just export a single frame PNG to the temp directory. By doing the image export Spine will run in GUI mode and should read your image files to update their actual size.
Another thing you can do is to restore the images to their normal size, open the project in Spine as normal, save (which will store the image sizes in the project file), then export via the CLI and it should use the saved sizes.
We will investigate having headless mode read the images if they are available to ensure it uses the right size. Decoding images is fine (that is why texture packing is OK), it's just loading them into OpenGL for rendering that requires GUI mode.
Another thing you might do is to avoid replacing the images. Maybe you can use skins to show a subset of attachments?
Starting in 3.0.17, headless export will update the images sizes, if the images are available.
