OK, I managed to isolate this to the mipmap. By default mipmaps are enabled and are used for high-quality downscaling. (This pre-processes high-quality resized images at 1/2 size, 1/4 size, 1/8 size etc. down to 1px). Unfortunately this works badly with spritesheeting: as the mipmaps get smaller, they blend more and more and cause bleed between unrelated images.
One possible fix is to disable mipmapping - but this reduces the downsampling quality, even with linear sampling. See this example (which includes the glitch bug with mipmaps, but notice the quality difference):
The correct fix is to pad images to a power-of-two size in the sprite sheet, and ensure they are aligned to power-of-two positions. Then since the mipmaps scale down by a factor of 2 every time, the images don't bleed at low mip levels. I tested this and it fixes the problem. However it comes with a high price: it effectively defeats the memory savings from sprite sheets, and in many cases can force animations that used to fit neatly on to one sprite sheet to spread over on to two or three sprite sheets. This could double image memory usage for some projects.
I think the best solution is to make an option in the editor. I'll add a 'Downscaling' property with three modes:
Low quality: mipmaps disabled, dense spritesheets
Medium quality (same as happens now): mipmaps enabled, dense spritesheets (minor glitches such as the one reported here are possible, but appear to be rare)
High quality: mipmaps enabled, sparse spritesheets (should never glitch)
Hopefully it's not too confusing an option to introduce, but I want to avoid either degrading the display quality, or increasing memory usage significantly for a relatively rare problem.