@Emi Unfortunately I have to state that re-using an AnimationReferenceAsset for a different SkeletonDataAsset (SkeletonData actually) is not generally supported, although it will work under certain constraints.
When playing an animation via a different SkeletonDataAsset's AnimationReferenceAsset, it's doing nothing more than applying the Spine.Animation of one SkeletonData to a different SkeletonData's skeleton. So it's applying SkeletonA.AnimationWalkA to SkeletonB, which might have no animations at all.
As Spine.Animations are applying Timelines to a Skeleton, which are mostly modifying bones, slots, etc at certain indices, this will go well as long as both Skeletons have the exact same setup (name and order) of bones, slots, etc. Unfortunately Animations that use DeformTimelines (deform keys, also called free-form deformation) will not apply the deformation animation to a different skeleton, because they don't use indices alone but also a direct object reference to a SkeletonData's VertexAttachment. This VertexAttachment object reference does not match the different Skeleton's VertexAttachment, and thus the deformation animation will be skipped, ignoring a part of your animation.
Also, it's just working due to the current way animation timelines are implemented, so it works by chance. More things might fail in future verisons of Spine like 4.2 or later versions, should the implementation change.
So in short, it is not recommended to apply animations to a Skeleton from a different SkeletonDataAsset. Sorry to say that!
Likely the best reliable solution would be to automate your workflow via scripting and copy the animations over at the Spine project level, and make sure they are exported correctly for each skeleton project. If the number of animations is a problem on the Unity side, you might want to automate your Unity project setup as well using editor scripting, e.g. automatically creating and assigning each AnimationReferenceAsset at each imported skeleton according to a template. This way you could save manual repetitive work and still ensure everything is playing back as it should.
