Thank you for the detailed help!
The Spine 4.3 beta has begun
I cannot properly launch 4.3 on Windows 11 Home 23H2. Happily I have launch window on begginig so I can easily go back to ealier version of Spine 
I can click only on News there.
Fantasmic! The new constraints interface is going to take some getting used to, but seems so strong. I know there are things I have done to try to replicate this exact functionality (ie trying to convert rotation to scale or translate etc) for complex (non game) rigs, but it never quite worked. Often having to nest constraints and bone constructs and IKS to get close. Which sucks when you have to also order the constraints as well!
Translating X Y etc directly into rotation or scale with clamps and multipliers is HUGELY useful for subtle rigging controllers.
I'll have to relearn what how the local/additive checks work, and offset has now been folded into the grid for the non 'Translate' properties.
I am assuming the left columns are input min and input max, and map to the right columns output min and output max, and the percentage in the middle is just the rate that gets the sides to match? I notice that changing the percentage manually gives unexpected changes so it seems to be more of an 'averaged result' than an actual lever to fiddle with.
inputMin (1st left column) --- maps to ---> outputMin (1st right column)
inputMax (2nd left column) --- maps to ---> outputMax (2nd right column)
Clamp is for the bones you want to change to not go beyond their min or max outputs?
Still trying to wrap my head around local on each side and additive! I think additive is more intuitive than relative though!
Awesome stuff.
You got it mostly right!
The percentage when you hover a curve is "scale". Mostly it's useful to know if the scale is 100%, meaning the mapping from input to output is 1:1 because both ranges are the same size. We don't want you to have to do math! It can also be useful if you know you want 25% or 200% of the speed, etc. When you change the scale, Spine has to change one of the ranges. It prefers to change the "from max" value, because the "to" values are usually what's most important. However, if a property has more than one connection, changing "from max" would change the scale for both connections, so it instead changes "to max". You can also ignore scale and just set the ranges. It's not a separate setting, it's just the ratio of the range sizes.
Clamp keeps the output values (the values set on the bones) within the right side range.
Additive is the same as the old Relative, just a better name.
Local allows you to use local or world values on each side. Note that world rotation is always 0-360, as it is just "the direction the bone is pointing". You'll get a jump when it wraps around from 0 to 360 or 360 to 0. Check Local to avoid the jump.
Note you can click to add a connection straight across, which helps make it less work when you want a simple constraint. Match with 0 mix does what you expect, but as you noted the offset is now in the ranges, except for offset X/Y.
We'd love to hear how it goes! Does it do everything you need? Is there anything missing? We are considering adding a Clamp setting to the left side.
Will these features be supported with export in Json Version 4.1?
columbussss No, you would need to update to 4.3 to use 4.3 features.
Nate I meant a version of the JSON export, not Spine itself. Like, will the data of the movement will be exported to a code correctly in a lower version? For example my game engine support 4.0 export, but I work in 4.2, everything works correctly except sequences.
You can find a more comprehensive response in Nate's replies here.
Davide Thank you. That answers my question.
新版变化约束个人使用之后，感觉可以增强使用体感的方面
1.属性之间的链接，能否像骨骼显示一样，可以往下拖动链接。目前鼠标左键右键都是连线，可以把其中一个改成往下拖到链接，对于想要链接所有属性的操作，会更便捷。
2.从左边属性链接到到右边，已有属性能否允许链接，然后原有的自动断开。目前链接已链接好的属性，必须先断开，再重新链接，有些繁琐。
3.这个链接的面板能否固定住，不乱动。链接面板有点小，当下面出现或消失新的熟悉的时候，他会上下跑，链接面板本来就小，属性的链接点更小，再乱跑的话，比较难选取。
以上是个人对新版变换约束的一些体验感觉。
Thank you for this very important feature. I've been waiting for something like this for a long time, and it's really going to make Spine so much more powerful. My question is, does anyone know the schedule for the Runtime updates to support the 4.3 features?
We've already started porting this feature to some runtimes (ts based runtimes and Unity) on the beta branch, but we haven't released them yet.
Which runtime are you using? If it's one of the above, you could build it from source, but be aware that the beta branch may contain bugs, and some fixes might not be ported yet.
It's a lot of fun!
It reminds me of a lot of fun settings with new features!
Thank you!
In the generation of the name of the constraint, could you please add '_' instead of Spacebar?
Spacing is very careful in programming.
Davide We're using the latest Unity runtimes. I'm not sure we're allowed to use Beta runtimes, but it's nice to know that we could at least test it out. I'm glad to hear that the Unity runtime update is close. This is going to be fantastic! Thank you again for the info.
Cool videos! There's a cat behind the door! 
Constraint names are strings and don't affect code. The issue with space is that it can't be seen and is relatively narrow. In a textual context it's uncommon to write nametoother without spaces (at least in English), but I can appreciate avoiding spaces in names to maximize clarity. However, I am not a fan of underscore. We could use hyphen -.
This so far has felt really fantastic to use, great job guys! The amount of doors that this opens already is really incredible, it's hard to think about just how useful this will be!
Not sure if it's been suggested already but given that, abstractly - the UI (and presumably the underlying implementation in the runtime) that's been built for this maps from one value range to another + the ability to clamp on either end, it would be incredible to have the ability to map any of these properties in the same manner but to the color channels / opacity on a set of slots.
Not necessarily on the transform constraint itself - maybe a separate constraint? dunno!
Same UI but with source being a bone with targets being a set of slots, and the same source properties Rotation, Translate X, etc.. just mapping to the targets H/S/V/R/G/B/A channels separately with the same Options as well.
Just my two cents from fiddling around with this for the past couple days - the power that I gain with these transform constraints makes me giddy, but I then get put down at needing to run back and manually key opacity/color changes for the otherwise totally automated bits of some of the rigs I've been fiddling with. In my eyes that's the biggest missing link to having a really powerful suite of tools to build out controllers to manage complex transitions between poses and a huge variety of other things!
yugutou Thanks for the feedback. Please try 4.3.14-beta, we've improved some of the areas you mentioned. We moved properties to the bottom, so they don't jump around.
We considered replacing existing connections when dragging a new connection, but it would only work on the right side and there is some worry it would be easy to accidentally replace a connection.
Dragging like in the tree is interesting. It's a little tricky, as we already have a drag operation for making connections, so we'd be dual purposing drag. Eg, you could drag down to create straight across connections, then drag to the right to make a connection. That makes it complex to implement. I wonder how often you really need all 6 properties mapped? It's more efficient to map fewer properties.
lightluxio Glad you like it! We have a solution in mind for mapping to slot color, attachment changes, and anything else that can be keyed. We should be showing it off soon!