I feel like there's an important feature lacking from the current constraints that would have tons of use cases, which boils down to scrubbing a timeline by a bone's position, rotation, or scale. With the introduction of physics this seems particularly powerful for auto-keying certain effects when specific conditions are met, but it's also very useful for a few other common use cases:

1. Spritesheets of rotated body pieces (hand, foot, torso, etc) that automatically swap out in a character turnaround. You'd just make a timeline of the image sequence frames, then constrain its playback position 0%-100% to a bone's rotation 0-360, with wraparound. This would link skeleton and image art in a very intuitive way on the more complex rigs that many people use for their characters, since hands and feet often aren't facing exactly the same direction as the torso in expressive and dynamic animations. You could even key automatic draw order changes for overlapping pieces!
2. Time-based animation effects. Animate a normal attack, then create a second timeline with a scrubber bone that goes from X=0 to X=500, linking that range to the playback position. You could punch a "time stone", break it, then play the attack in reverse, or glitch between different points in the sub-timeline, or play at 50% on contact and then continue at 100% afterward for a bigger impact. Any timeline playback could be directly keyed via the bone's position.
3. Physics-based animation effects. Maybe you want a character's hair to shine when physics pulls it back to a specific angle (reflecting sunlight)? Basically any number in the program could become an equation with defined effects. You could even trigger sub-animations when bones hit certain values, and for unpredictable physics values this would be extremely valuable.

A lot of this is currently possible in-engine via the API, but that does not make it animatable within Spine, with that kind of instant visual feedback. My idea would be to add a scrubbing constraint with these params: constrained animation, linked bone, value type dropdown (pos rot scale skew X Y), 0% playback value equivalent, 100% playback value equivalent, and a wraparound/clamp toggle box for bone values outside of that range.

Possibly also have animations that trigger when you go below the minimum value or above the maximum value (on crossing that threshold for the first time in that direction, so wraparound still works), because then you basically have bone events. This seems complicated and only marginally more useful, though.

Misaki To help with visualizing, here's some art I drew:

Imagine a character turnaround that uses all of these hand frames at different angles. Rather than manually swapping out each art frame as the character's arm turns around, I would like the ability to create a (manually spaced) sequence of these images and then link it to a bone's rotation, so I could get easy ease-in/out on my images, etc. This would be useful for multidirectional rigs, like this one by armanimations. As you can see in that video, currently Spine struggles with complex rigs like this, as the animation process of swapping frames at the end was very manual and tedious.

Nate The 1d/2d sliders are also a very cool idea, and could be an alternative to using timelines. But I feel like so many animation tools are already coded to work with timelines that it might be easier to repurpose them? By linking a timeline to a bone property you'd basically be creating curves by value instead of by time, so it's more for automating basic tasks than direct use. In the use case described above, I would not be altering this bone-linked timeline after the image sequence was properly laid out to match the bone angles, and I would actually want it to be decoupled from the other animations I was working on. It's sort of a baseline "what draw order and hand frame are typical when the player is facing this direction?", that only gets manually re-keyed when necessary.

Using sliders would also solve the problem though, so I'm looking forward to what you folks come up with as a solution. I just definitely want a way to link bone properties to ranges in the sliders, as it solves a lot of the image art <-> skeleton linkage issues I'm having right now.

Sounds great! Just to be clear on my last point about sliders, I guess I'm talking about an additional "slider constraint", that automatically moves the slider position based on a chosen bone property and range. While manually keying the slider position is fine, I really want something linked to existing properties that doesn't have to be keyed at all. For things like physics, it makes sense that you don't want to have to meticulously match a curve to what it's doing automatically.

For more, unnecessarily detailed info:
The end goal for my turnaround example above would be similar to how isometric setups work currently, with an x-scaled bone parenting a rotatable bone to get oval-shaped rotation. You can then make a bunch of these oval-like joints centered on a rotation axis, to position every joint by its distance and angle from that central axis, defining your character in a 2.5d/polar coordinate way. By then linking the rotation offset of the child bones to a master "rotation" control bone that offsets them all, you can animate something like a walk cycle once and get a full 360 degrees of walking animations for free. In code you can just change the rotation of one bone via transform constraints to turn your character to the correct direction, and all the ovals swivel to that offset. But most importantly, if you want arm rotation to be decoupled from the body for better animations, you can just nest 2 control bones via transform constraints to get a "master" controller and an "arm" controller.

This rig setup mostly works in Spine right now, the only problem is that the art/attachment layers don't understand the concept of a control bone or the transform constraint, so draw order is static and also art frames have to be manually swapped out. Currently I can make a separate turnaround animation that has the correct draw order and art frames at every angle for every piece that rotates independently, then blend them in code by freezing animation layers and manually setting them to the correct turnaround point, so it somewhat works in runtime code. In Spine though, this is impossible, so I'd have to check all my animation angles post-export to do any kind of cleanup.

I feel like there are a lot of use cases where these kinds of art control bones would be helpful to the animation process. So yeah, not really a core feature, but very powerful in certain circumstances, like with physics and "3d" rigs. I feel like this is a situation where a picture is worth a thousand words though, so I'm going to stop rambling, haha.

So I just learned about Moho, and it turns out they have a perfect example of what I was suggesting here! Their feature is called Smart Bones.

This may only let you map a bone's rotation to poses, but the additive blending (since each timeline only affects some values) and ability to make bones move with physics (for automatic follow through at the end of a head turn, etc) is what really makes this concept powerful for Spine too, imo.

It might be worth checking out their software to see how they handle this, if you're interested in a live demo of the feature. Gives you all of the research with none of the dev time.