I’ve done a bunch of testing of this too and there’s definitely a limit. in these cases where there’s a smooth motion but with a changing speed I’ve found its best to try match the fastest speed. in your clip she seems to be going faster as she goes down than when she goes up. even though if you script from the very last frame she stops moving up/down they may be the same distance and end up with a script that has the same speed up and down. so adjusting the points slightly so it doesn’t match the exact frame, but matches the speed on the way down better then it should feel more accurate.
The exception I’ve found to this is with very slow speeds or with very large changes in speed where the change in speed is supposed to be highlighted. Like to simulate resistance or tightness. It still results in a judder from the toy as the speed changes but that adds to the effect rather than ruins the smooth motion.
One example from one of my scripts,
that section at the start, where there’s a quick movement, then it slows a lot but still continues, and then suddenly goes fast again.
or this one, where there is a whole bunch of different moments where it is drastically slowing down at the bottom of the moment at a moment when she is reacting and then bottoms out at another moment when she is reacting. These scenes they are actually just touching themselves, so there’s no penetration but the reaction is what sells it as if they are tightening up or reacting to “you” changing speed, changing direction. If a scene was filmed like that then this sort of scripting with speed changes would work. So some edging videos possibly have such a drastic slow down of movement in hj/bj scenes, but if its a subtle change of speed you’re better off like i said, trying to match the fastest movement.
You also have to factor in the way application smooth out the points. Like in openfunscripter most software now seems to project a quadratic or cosine curve through the points, with that method in picture one those changes of speed points can have the opposite effect. i think even though the OFS is doing a sort of point to point calculation for the speed that it give on the side panel and represents with the colour of the line. the actual curve might be very different. If you look at the middle section on your first photo the white section at the top would ideally be a smooth shallow curve up to the very top and only reach the very top right on the second point. but projecting a curve and it just peaks right up to the top within the first couple of frames, flat lines for the next dozen frames and actually looks like the movement of those first few frames is actually faster then the curve before it even though its white.
I think ideally vectors could be used in scripting to get smoothly changing rates of speed, but like one of the other guys mentioned its also hardware and firmware limitations. Like the handy needs a 100ms gap between commands. Ideally with vectors you wouldn’t need to send more commands than a top and bottom point but the hardware would have to be capable of taking vector commands and converting them to very high rates of variable speeds