@JulianRice Sorry for the delay. This has been a long standing issue with Unity.
Solutions seem to be using Accelerator or Cache Server, depending on your Unity (asset pipeline) version:
https://docs.unity3d.com/Manual/UnityAccelerator.html
https://docs.unity3d.com/2022.1/Documentation/Manual/CacheServer.html

It's somewhat puzzling that they have never provided a simple Editor Preferences setting like "use separate directories" to write to a separate Library directory for each platform. This is something which many users have been using in the past, effectively switching platforms via a scripts that changes the active platform in a text file and sets the symlink from Library to the respective Library_platform directory.

@JulianRice @jeremie-tmx We have just pushed a commit to both 4.1 and 4.2-beta branches which should fix the issue. New unitypackages are available for download here as usual:
https://esotericsoftware.com/spine-unity-download

Details: The commit reverts the structural change of distributing the UpdateMesh procedure into LateUpdate and Rebuild which introduced the possibility for modifying the skeleton attachment state at the wrong time.

Issue ticket URL for later reference:
EsotericSoftware/spine-runtimes2487

@JulianRice Sorry to hear you're facing this issue as well, thanks for your detailed writeup. Unfortunately the stack trace where the exception happens is already known, the question is which call modifies the skeleton's state before SkeletonGraphic.Rebuild is called. As mentioned above in previous postings, if user code modifies visible attachments after SkeletonGraphic.LateUpdate() but before SkeletonGraphic.Rebuild(), things could go out of sync. However, we've already added an automatic check when accessing SkeletonGraphic.Skeleton between these calls and trigger a second update automatically to re-sync SkeletonGraphic to the modification. Modifying the skeleton through a cached Skeleton skeleton = SkeletonGraphic.Skeleton however would bypass this safety check and explain the exception. Are you performing any modification of active skins or visible attachments from LateUpdate() in your scripts? If so, could you please share your exact code? If you're uncertain, you could perhaps add breakpoints in Skeleton.SetSkin and Slot.Attachment.set, or if that's not catching anything: add Debug.Log statements in said methods to see if any SetSkin or Attachment.set call at runtime lies between LateUpdate and Rebuild.

JulianRice Could this be as easy as going through all of the NPCs in the town, resetting the SPINE (whatever default assets/materials are set already), building, and testing it again?

I'm not sure if I understood this sentence correctly. If you mean that you could create a minimal Unity project by reducing the number of skeletons until only the problematic skeleton is left which still causes the issue in the built executable: that would be great! If you could provide us with such a minimal reproduction project, please send it to contact@esotericsoftware.com, briefly mentioning this forum thread URL so that we know the context. Then we can have a look at what's going wrong.

JulianRice Based on the stack trace, the LateUpdate() from Unity's ScrollRect is triggering this error, but only four times... so there has to be some kind of mismatch or issue with timing.

The issue occurs only when more attachment vertices are required (and written to) than are available. When things get out of sync the first time, an out-of-bounds exception will be raised, but when activating the same or a similar skin later, the vertex buffers likely have already been enlarged to sufficient size to cover the new skin, even if it's a different set of attachments now.

JulianRice I'll keep taking a look and will keep you updated, but please let me know if there's anything else I can do to find out the issue for this (and why it seemingly only happens in builds!)

Thanks very much for your offer! We are currently performing some more investigations on our side, but would be very happy if you could see if you could perhaps create a minimal reproduction project as described above, of check whether any calls that change the skin or attachments happen.

@JulianRice Since you're using Linear color space in Unity: Are you perhaps using (the default) Gamma color space in Spine? See the documentation below on how to switch the viewport color space in Spine:
http://esotericsoftware.com/spine-settings#Color-management

In general you might want to consider whether switching from Linear to Gamma color space in your Unity project would be better, as any blending will be quite unintuitive in Linear space and not what you're expecting from e.g. Photoshop (especially with very transparent pixels). Linear color space mainly makes sense when you need physically correct lighting computations at different angles and intensities, which is however quite often not needed at all in sprite-based games. See this rather recent conversation here.

@JulianRice Sorry to hear you're having troubles. Please note the following sentence in the documentation here.

"Any SkeletonGraphic component using this CanvasGroup compatible material needs to also have Advanced - PMA Vertex Colors disabled to avoid a double-darkening effect of semi-transparent parts."

Could you please check whether this resolves your issue?

In general you should only enable CanvasGroup compatible at a SkeletonGraphic material when you're placing the skeleton as child below a CanvasGroup with alpha (transparency) set to a value lower than 1.0.

@JulianRice No need to apologize. Thanks a lot for getting back to us and for filing a bug with Unity, looking forward to the fix!