1) In Spine's system, images are assigned to slots, and slots are ordered in a list. Their order in the list determines the order they are drawn. Bones aren't really related to this. But I get what you mean.
2) Spine-Unity uses a MeshRenderer to facilitate the FFD and skinning features.
3) The only reason it was programmed to use only one Renderer was to minimize overhead, though Nate has mentioned that he's open to an alternative code for rendering 'cause we really haven't seen how much of an effect on performance it has if each slot has its own renderer (and therefore, it's own GameObject and Transform), or what grouping scheme could be made.
It's just that he has to take care of the promised standard features and other runtimes too so it's kinda up to us if we need something specific until it gets declared as a feature and implemented ('cause other runtimes can't solve this draw order problem yet either).
(@[borrado], Shiu) This gives me an idea. In Spine Editor (and the Spine system in general), what if you could add a marker to the draw order list that signifies where the rendering in-game can be split. Then runtime code can know where to split the skeleton into two batches of slots to render, and users can squeeze in rendering between those batches.
So instead of limiting the functionality to a SkeletonAttachment, anything renderable can be rendered between everything before that marker and everything after that marker. Just a thought.
In Unity, this might signify a use of an extra Renderer whose Sorting Layer/Order might be settable separately. I'm not sure if this somehow works for other runtimes, though I do think it's hackable into Spine-Unity just with currently exportable Spine skeleton data. The marker would just be a specially named slot.
4) Others have wondered how to do this too but there hasn't been a definitive best way. Look up the user who tried to do stuff like animate the character riding on a horse. XD One of the solutions was to split the skeleton manually. That one's a bit messy to do.
