It's coming in the next version, 4.0.21-beta.

There is some info about the beta and a video that takes you through the basics here:
Blog: Spine v4-beta: it has a curve editor!

Friebel wrote

ease IN is slowly at the start, faster at the end and ease OUT directly starts and is slow at the end

I don't think this is quite right. First, these terms are applied to the transition between two poses. We transition "out" of the first pose and "in" to the second pose. Next, "ease" means to move more slowly. When you "ease out", the transition starts slowly from the first pose (compared to the speed later in the transition). When you "ease in" you move slowly into the second pose. Note that you can have a transition that eases out and also eases in.

I agree it's important and it's one of the 12 basic principles. Here's an image from the Animation Survival Kit that helps visualize it:

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

I think the terms "slow out" and "slow in" are a bit better, and they match "fast out" and "fast in".

Interesting research!

To restate what you wrote, in/out can be interpreted as:
A) Transition-centric: "in" means the start of the transition and "out" means the end. You'd say you are going slow/fast into or out of the transition.
B) Pose-centric: "out" means the part of the transition near the first pose and "in" means near the second pose. You'd say you are easing out of the first pose or into the second pose.

Friebel wrote

animations are curve-focussed (type A)

Not sure this is definitive, since it could easily be said animation is pose-focused.

Friebel wrote

when working with both Spine and Javascript or other animation code libs together it's very confusing to use both systems together.

Note the only place Spine uses in/out is in the graph video and likely in the upcoming tutorial video series. It's not found in the UI, API, or documentation.

For me, using Spine is primarily about animating and that the Animation Survival Kit and 12 principles are pose-centric indicates that is probably the way animation software should use the terms. I would not copy what other software uses since there is no insight into why they made such a decision. There can be value in matching what everyone is doing, but if it's a split then it's better for us to be correct than popular. I can see it being easier for tools/libraries that have no concept of poses to confuse the terms.

Siniša, who voiced the video, surely has some input. He's a professional animator with a lot of experience and I defer to him for this decision. Let's see what he thinks on Monday.

Either way the most important thing is to be consistent to avoid (further) confusion. It wouldn't make sense to use the terms when talking about poses, then use the same terms for the reverse meaning when talking about transitions/curves.

Hello Friebel, let me clear the confusion,

Friebel wrote

There is a mistake in the video though: the voice over is consistently confusing ease IN and ease OUT. Around 7:15 he is talking about ease OUT, while he is showing an ease IN. And after that he says ease IN, while explaining ease OUT.
A curve always goes from IN to OUT, not the other way.

There is no mistake here, the video and the content were carefully thought out to give the users the best info about the Graph and animation jargon.

Friebel wrote

I think it is too important to not mention this here. Please use the right terms in videos as for beginners watching this video and never worked with easing before, with this video they learn it the wrong way causing confusing and miscommunication with others when actually using it in real life.
He says it so many times consistently wrong in this little tutorial that I would advise you guys to re-record the video with the right terms to prevent beginners learning it the wrong way. It's hard to correct when learned wrong and used for years.

I can understand the confusion, for that reason I specifically showed what is fast/slow out and fast/slow in, as I noticed for years people are getting confused with basically a very simple topic. That's why this video is perfect to learn the right way.

To put things in perspective, the term slow out/in (or ease out/in) was created by Disney's nine old men, and it's one of the 12 basic animation principles. They were created in the 1930s, so that was around the time Alan Turing presented the notion of a universal machine. It basically means that you slow out of the pose/drawing or slow in to a pose/drawing. I understand that is the opposite of the code but it's a term animators were using for years before code was even invented and still use to this day, so it would be actually a mistake to teach the other way around.

Friebel wrote

If I were to write animation-software that's extensively used for code, used by developers and used for internet and games, like Spine, I would choose for method A without a doubt, so IN is left and OUT is right of the curve, so focus on curves.

Animation software is made to be used by animators. Animators do not care how the stuff is called in code, as we will probably never look at it.

Friebel wrote

Google, CSS, Greensock, gamelibs, flash/as3, threejs, createjs etc. all chose type A (perspective on curves, IN is left, OUT is right) and the developer world seems to have chosen the same in general.

Again, the code is not in the focus here, the art of animation is. I will continue to teach the animation theory the same way I was taught by Disney, PIXAR, Valve, Weta, etc animators. All my lectures and videos are based on the lectures I received from them over the years.

Friebel wrote

You seem to divide people into Animators and Developers though and you practically wrote you don't care about code. I'm very surprised about that and it felt degrading to developers.

I feel you are reading too much into Sinisa's post. He is an animator and was speaking from an animators perspective. An animator really does not care about code, not out of disdain but because they are never going to read or write code, look at APIs, etc.

Overall Spine of course cares about both, provides APIs, and programming is a big part of Spine's workflows. However, the animator relevant parts of Spine are separate from the programmer parts, even if in some cases the same person is doing both. It makes sense to use animation terms in the animator relevant parts rather than adjusting the terms based on the programmer parts. The Animator's Survival Guide, Sinisa's extensive education in animation and real world experience as an animator, and other sources indicate that the terms in the animation domain are used in the pose-centric form, so it makes sense to use that for the animator relevant parts of Spine.

Your research is really interesting and shows there is widespread confusion surrounding the terms. As Sinisa mentioned, they were originally animation terms using the pose-centric form and were later reused with the opposite meaning for other, if related, purposes. It could easily be argued that was a poor choice and different terms should have been used rather than muddling the animation terms.

The pose-centric terms are still in use in the animating world and it's unlikely the opposite usage will cease, so there is always going to be confusion, no matter which we choose. Given that, we feel the pose-centric/animation focused terms are appropriate for Spine. As I mentioned, the terms are not used in Spine itself, nor in the documentation. They are only used in the tutorial videos which are teaching both animation theory and how to animate using Spine. It would not make sense to teach animation theory using the opposite meaning for animation terms. That is probably the most important point.

Friebel wrote

I really think in 2020 there are very very little people doing even the slightest thing in animation nowadays that never heard of that book or at least the 12 principles.

That book and the 12 principles are the animation bible. I would go so far to say that any serious animator is very familiar with both and if they aren't, they should be.

Friebel wrote

Your post also gave me the strong feeling you skipped all my concrete examples of actual tools and market leaders of animation software in the world Spine is in and actual real life uses cases of animation used for internet and games Spine is made for upfront.

Not at all and I specifically addressed that:

Nate wrote

I would not copy what other software uses since there is no insight into why they made such a decision. There can be value in matching what everyone is doing, but if it's a split then it's better for us to be correct than popular.

We try very hard not to make decisions solely because other software does so. We strive to make decisions based on relevant considerations so we can better innovate and improve things. As one example, Spine does not have right click context menus (because discoverability is poor and tend to become junk drawers) and that has worked out quite well, despite being maybe the only software to avoid them.

Friebel wrote

I get it that it's difficult to embrace another opinion about something we learned and used for so long. We all been there at one point. But I was hoping for a little more open mind.

I can't see how you can come to this conclusion when we have provided extensive reasoning for our decisions.