Are you repacking the skin after swapping attachments? While repacking saves the draw call overhead from using multiple textures, it will cause a single larger performance overhead when repacking the texture (cause a short "hiccup"). If multiple draw calls are not a problem, you might delay repacking to a later non-critical moment during gameplay.
DanielThomas wroteAdding a damaged part as skin looks like an option, but then that would multiply the skin by 5. Maybe it's not a problem other than a bit hard to manage in Spine?
Performance-wise this should be the best option, since you can pre-arrange the grouping of attachments in your atlas textures as needed, and it comes with less overhead than when swapping attachments with Sprites and repacking the skin to a new one.
Regarding organization in Spine: You would then for sure use folders to arrange your skins in. This should then be just as equally easy or hard to manage as having lots of Sprite images in Unity.
DanielThomas wroteCould one have, in the spine project, the damaged attachment in another slot and hide the original and show the damaged slot at runtime? Would this give less of a performance impact?
While you could go down that route, I don't think that this is a clean way to handle it.
There is no performance benefit at all, instead you will rather see a drawback for having 5x as many slots. Anyway, you will likely not receive any measurable performance difference by the number of slots when having the same number of attachments active. Performance will likely depend on other factors, such as the number of draw calls (different textures), the active vertex count, and the like. See the documentation on performance here for further info.
