Wonser wrote

Additionally, when setting up IK controls within Spine, Do they have a toggle to allow stretching of the sprite, scaling along the bone/joint as the control is pulled beyond it's normal bound?

It's currently not a checkbox, but it can be done by binding a path to both the IK bones and target. You can see the stretchyman example project or play with the demo here:
Spine: Demos: Path constraints
This is definitely not the only way to use paths, nor the only way to rig limbs. However, it does provide scaling of the limb when the IK target is out of range. There are other benefits too, such as being able to manipulate the path to get a smoother or sharper bend than a single knee/elbow joint allows.

Making it as easy as a checkbox on the IK constraint is not actually terribly difficult, so we've added that in 3.7.20-beta. :party:

Image removed due to the lack of support for HTTPS. | Show Anyway

Pharan will be along shortly to address your Unity concerns and questions!

Each of your options have their own pros and cons.

DATA
For the best coverage of Spine features, Spine skeletons and animations are not converted into Unity assets. (Skeletons and bones are not converted to prefabs and GameObjects. Animations are not converted to anim files.)

Spine has some features and systems that either Unity's Animation system lacks or does drastically differently. By default, Spine data is loaded straight from your export (.json or .skel.bytes for binary data).

This can mean a number of things, including that animations are solely edited in Spine and come from the Spine export. Animations don't have incongruencies when you export from Spine and import into Unity, they behave identically as they did in Spine.

CONTROLLERS
Spine has its C# Spine.AnimationState API, which is far more low-level than what Unity gives you out of the box with its Mecanim state machine. You can write your own controller to make calls to it. You can also write Mecanim StateMachineBehaviours to make calls to it. (We're working on an example scene and assets for this. It should be included in the next version.) Any of the special features that Mecanim supports would have to be handled as needed.

The paradigm here is primarily that you would use Mecanim as a logical state machine with Spine commands tied to it, rather than use Mecanim as an ANIMATION state machine.

The alternate option is to use "SkeletonMecanim" (previously called "SkeletonAnimator" in 3.6 and below). This generates a Mecanim controller and dummy Unity AnimationClips, and uses a Mecanim state machine to drive the skeleton animations. The AnimationClips are mostly empty except for events and the duration of the animation. They are only used to keep track of time and which animation is being applied. This option is more along the lines of using Mecanim as an animation state machine and things like blend trees are supported out of the box.

If you are used to working with Mecanim but don't want to have to code some extra things, it's likely the most comfortable route available at the moment.

To use SkeletonAnimator/SkeletonMecanim, you just need to instantiate the skeleton into the scene as the right type. If your controller and dummy animations don't exist, they will be automatically generated for you.

Image removed due to the lack of support for HTTPS. | Show Anyway

Many users have used these different options with success. Which way you choose to do things really depends on your needs. But if you run into any problems, feel free to post and ask questions here on the forums. Spine and Spine-Unity are still continually being developed as new features are added and as Unity has also changed over time.