ECG_Kinsey You can import animations from another Spine project via Import Project.

For your information, importing animations cannot be done through the CLI, so if you create your characters as separate skeletons, and you update an animation in one of them, the only way to reflect that update in the other skeleton is to import the animation manually.
We plan to improve this in future releases and have an issue ticket for it, but we are not sure when: EsotericSoftware/spine-editor379

In other words, if you want to share animations between many characters, the easiest way to share animations is to create the character using skins. By using skin bones and skin constraints, you can create multiple characters with a single skeleton, even if the bones and constraints required for each character are different.

@ECG_Kinsey Unfortunately machine translation of your text was somewhat ambiguous. Are you asking whether loading this skeleton leads to long load times due to a lot of atlas texture pages (many textures)? Or are you concerned about a lot of bones, constraints, and so on leading to a larger skeleton.skel.bytes file to be loaded?

Regarding atlas textures, you could use on-demand loading of only the currently needed atlas textures. We provide experimental UPM extension packages as described in this issue ticket:
EsotericSoftware/spine-runtimes1890
Otherwise whenever the skeleton is loaded by a scene, all atlas textures would all be loaded as well since the atlas textures are referenced by the materials, which are referenced by the AtlasAsset, which is referenced by the SkeletonDataAsset.

Regarding loading additional skin bones and skin constraints: this will add a bit of an overhead, however it should not matter much compared to loaded atlas texture size.

You can disable scale inheritance so you can scale the bone to make it longer without affecting child bones. Your bones would look like:

leg > legAttachments > regions/meshes

The legAttachments bone would have Inherit: Scale unchecked so when you scale leg, the attachments don't scale. Of course you will need longer attachments for a character that is taller. You'll be able to see how everything looks in the editor.

Alternatively, you could adjust bones at runtime. You could increase the length of a bone (and move child bones that amount if needed). if you change the setup pose (SkeletonData class) it will affect all the skeleton instances. You may want to change the instance data (Skeleton class) and apply these changes each frame. Doing it this way you won't be able to see how everything looks in the editor.

That's why I added a legAttachments bone after the leg IK bone. Disable scale inherit for legAttachments and move your slots under that bone.

ECG_Kinsey I don't think the IK constraint has anything to do with this case in particular, the only issue is when you set the parent of the image attachment to a corresponding bone. The following is a very simple example, but I am assuming you are looking for a rig like this, is my understanding correct?:

Here is the Spine project files:

What I did should be almost identical to what you were trying to do. I imported images of another character and adjusted the transform of the bones to match that character's arms using transform constraints, then added the constraints to the character's skin. I then set the parent of the images to the corresponding bones. This allows you to place another character's attachments without affecting the position of the first character's attachments.
I hope this will be of help to you.

ECG_Kinsey (Except for the IK issue you just posted, this is an answer to your earlier question on the matter.)
I think your understanding that you need to move the attachment is correct, but it's hard to explain well in words, so I've recorded the process of setting up the example I just posted above and uploaded it below so you can take a look at it:

ECG_Kinsey Hmmm, as far as I have tried on my end, changing the bone scale in the transform constraint does not produce that result. I've attached a updated Spine project with the results of my own testing (in skin B I scale the arm bones via the transform constraint UpperArm_Position_B):

Perhaps the quickest way to confirm your problem is to see your Spine project in person. A minimal Spine project with irrelevant parts removed would be fine, so could you email it to us?: contact@esotericsoftware.com

Bone and attachment (Images) compensation affects manipulating bones in the viewport. It does not affect applying constraints. It is not applied when adjusting a transform constraint.

You are fine up to this step:

If I understand, you parent the slot to the root bone, apply the transform constraint, then parent the slot back. That puts the arm in the right position, but in your original skin the arm moves. Is the arm that moves in the same slot? If so, then you can't use parenting the slot to the root to move your attachment. Instead, parent only the attachments in the second skin to the root bone in a new slot, apply the transform constraint, then parent them back and delete the temporary slots on the root bone.

As a simpler test, instead of changing the parent of attachments in the tree, just manually move the attachments to be in the right place in the viewport. Each attachment has its own position. Moving one doesn't affect other attachments in the slot or in other skins. (Except for linked meshes, which share the vertex positions.)

For your IK scaling problem, you probably need to set the transform constraint to local and possibly relative. In general it's not possible to tell what is going on from an image or GIF. If you can send a .spine file it would be easier to provide guidance.