You could import all the relevant non-packed pngs in Unity. Then you could implement building a texture and atlas at runtime. Definitely doable in Unity 5.

With that setup, you wouldn't have the workflow nightmare (exporting a million atlases), and you'd get great performance and memory usage outside of equip mode.

What do you mean by "sprite switcher" anyway? Is this a thing that's built-in somewhere? Sounds like using it may not be a good idea to use it if you have this problem.

But in general (not specific to Unity) it may be helpful to make sure, when you're designing/drawing your images, that your equip variations share the same size/dimensions and ideal pivot, or group them according to similarly sized groups so you only have to align at most 3 or 5 times, instead of 100 times.

The other thing I meant was that yes, you could "build it into spine". ie. align the attachments in Spine and store attachment data with the json. But not let Spine do the packing.
You could also avoid having to define 100 unique attachments in Spine (and avoid the overhead of storing 100 unused attachments on your SkeletonData object) if bunches of your images were the same size. Then you could just custom-populate your atlas based on the knowledge that certain sets of images and resulting attachments would have the same pixel dimensions and pivot/offset.

"Dozens of atlases" used by one skeleton is actually supported but, for performance reasons, not recommended. So to be clear, you could, but you shouldn't, and you don't have to.

We're doing something similar in our game and unfortunately since we pack our textures into our own atlas and strip the whitespace out we had to manually set pivots for each individual image. This involved building a rather large system that read in files that arbitrarily defined "equipment slots" that had sets of spine slots and then specifying on each type of "equipment" what images went on what spine slots and what the pivots were. So I can confirm that what you want to do is indeed possible.

If you're not stripping whitespace then I would do what Pharan suggested and just make sure everything lines up on the same pivot in the images themselves.

As far as mesh deformation goes (and please someone correct me if I'm wrong) I believe that since you're using the sprite attacher you're in the same boat as we are. In my understanding mesh deformation is tied to the image attachments in Spine, which means you can't do a single deformation for a slot and have it affect any attachment you decide to place on that slot. This topic seems to discuss this problem: viewtopic.php?f=11&t=2184&p=10895. If you're not using your own texture atlas you can probably still manually do the mesh deformation for each image, but that is not an option for us unfortunately =/

Hopefully sometime in the near future mesh deformations can be reused for multiple attachments.

EDIT:
As far as your issue with your code adding slots, that definitely seems like a bug. In our implementation we just swap out attachments on the slots that have already been defined in Spine.

Also an important step that I forgot to mention in our implementation is that we dynamically generate a skin and set the attachments for each spine slot that the "equipment slot" needs on that skin, then set the skin to the skeleton. Something like this:

foreach(int i in slotIndecies)
{
// psuedo-code
sprite = GetFromAtlas();
slotName = skeleton.slots[slotIndecies].Data.Name;
newAttachment = (RegionAttachment)skeleton.AttachUnitySprite(slotName, sprite, shader); currentSkin.AddAttachment(slotIndecies, skinPlaceHolderNames, newAttachment);
}

And you would reuse the same skin for each "equipment slot" so that all your equipment combines easily. We just stored a map of these skins so that we can use different skins on the same model for different characters and then we clean them up whenever we don't need them anymore.

Since it looks like you're not using skins that might be the source of some of your troubles. I would look into trying to dynamically create a skin and see if that fixes your slot addition issues.

Depending on how big your atlas gets you might not be able to fit all of your items onto it and still have it be an appropriate size (we're on mobile so we're limited on space). The runtime cost isn't the problem since that should just be a texture coordinate change since its all on an atlas.

As I was saying in my last post, I'm not the most knowledgable on the mesh deformation process, but I believe that since it is tied to the attachment in Spine you have to do it manually for each item that needs mesh deformation information. If you swap out a robe for a different robe, they both need to have the mesh deformation animated on them inside Spine. Then when you export from Spine that information gets stored in the .atlas file and references locations in the atlas image that was created by Spine. (Once again please someone correct me if I'm wrong on any of this.)

To make a long story short, you can't reuse mesh information regardless of what method you pick, and as far as I can tell if you want it to work at all you need to export everything from Spine since the mesh information references locations in the image atlas generated by Spine. I really do wish Spine had better mesh deformation support because it is such a great tool, I just hope that sometime in the near future some more work gets put into it to make it a bit more flexible for use cases like these.

If you don't have problems with your atlases, great!

Defining what slots a "Leather Tunic" affects is definitely what we did. Though we extrapolated it slightly further and said "Tunics" have these slots and then a "Leather Tunic" places these sets of images on those slots.

When I was talking about skins earlier you're not actually defining the skin in Spine, you're just dynamically creating one at runtime from the different attachments that you want, otherwise you're going to run into issues if you want to key different frames for your "Tunic" during any of your animations.