Well, Unity may be a good example for you.
Usually, a SkeletonRenderer render is rendered whole. ie, when you tell the Spine runtime to render it, it'll render all the parts, from the first slot, to the last slot. And then allow you to render the next thing.
A feature was added to Spine-Unity that added the ability to split that render into parts; so you can render one half of the slots of the skeleton, then arbitrarily anything, then render the other half.
This allowed us to draw anything— Unity sprites, particle systems, 3D meshes, other Spine skeletons— between the parts of a character.
The other part of this is that we have a simple transform-following script which allows another object to follow the position and rotation of a Spine.Bone.
With these two features, it's conceivable to make, for sample, two skeletons: a character skeleton, and a weapon skeleton.
Animate them separately.
Then render the weapon skeleton between the parts of the character skeleton, and make its transform follow a weapon-holding alignment bone.
The downside here, because Spine editor doesn't have explicit support for this feature yet, is that you can't preview it in the editor and can't do actual alignments there. But you can do alignments with placeholders.
The other downside is that if your weapon involves two versions depending on the view, like a fake 3D rotation, (1) you'll need some way for your character to communicate when that happens. Maybe an attachment keys. Maybe events. (2) You'll have to manage this switching yourself at runtime.
If you choose this way, you'll need to read up on a couple of things based on the runtime you use to get started:
(1) How to get a bone's transform properties and apply it to another object (or another spine skeleton). This is pretty easy but it'll also change in 3.0 runtimes. Read about the Spine.Bone
class for this.
(2) How skeletons are rendered. And how to render only a portion of those slots, so you can stick something in between. This may be super easy in your runtime... or kinda crazy like in Unity. Rendering is pretty specific for each runtime so I don't think this part is in the documentation. Just look for where it happens in your runtime and read the code.
I don't recommend reading the Spine-Unity runtimes as an implementation sample 'cause it's jumbled up in Unity classes.
But do read the official Spine documentation in this site.