Thanks for the second test project! It shows the problem differently and was helpful.
As Harald mentioned, this is a garbage in / garbage out situation. It comes from using images that have arbitrary colors for pixels that have 0 alpha. When the image is sampled for minification (zoomed out), that color data is mixed with neighboring pixels that have alpha > 0 and can be seen. This didn't happen in older versions of Spine because we used to multiply the color by the alpha for each pixel when images were loaded. We can no longer do that now that we have color management because we support blending colors in gamma or linear space. Applying the alpha before the colors are blended would wreck the colors.
A good way to fix this would be to apply color bleeding to your images so that the 0 alpha pixels have color data from the nearest > 0 alpha pixels. Not many image editors support this, if any. Spine's texture packer can do it and we could provide a tool to do it, but I doubt many people want an additional step in their workflow.
We've got a fix for it in 4.0.43-beta: we apply color bleeding when images are loaded. Doing that slows down image loading slightly, eg spineboy's images takes an extra 16ms for 1px of color bleeding on a moderately powerful laptop. A very large project that uses massive images takes an extra 600ms, which is about the worst case. However, that is for just 1px color bleeding, which fixes OatmealMu's problem. To fix HyperSSam's problem takes 8-10px of color bleeding and that takes 5-6x longer than 1px. That is still fast enough to be acceptable for many projects, but projects with many large images could take 4 seconds longer to load the images.
Given than 1px doesn't add too much to image loading times and fixes the problems for most people, we've made that the default and added a setting to allow choosing 0-16px of color bleeding.
