LinuxCNC S-Curve Accelerations

It seems to me that driving a car on the road, it's possible to follow the road while accelerating and jerking. I means you must spend time accelerating and jerking.
We trade time for acceleration and jerk not position.

The idea of jerk control planning it to actually calculate a definitive jerk rather then ignoring it. AIUI this allows increase in acceleration which offsets the loss of slowing down for jerk control.

Your observation that gcode doesn't describe jerk is also true for acceleration.
The feedrate set in gcode is often not followed do to this.
In linuxcnc now there is also a tolerance for position vrs speed.

The car analogy is a good one. If you had a road with an immediate transition from straight to a circular arc (as the g code describes), it would be impossible for you to stay exactly in the middle of the road without coming to a complete stop at the transition and then turn the wheels before accelerating again. To pass the transition at any speed > 0 and keep exactly in the middle of the road, your wheels would have to instantly jump from pointing straight forward to pointing at an angle suitable to follow the curve. That would be infinite jerk. So the only way to drive through such a transition at speed > 0 would be to deviate a bit from the middle of the road.

It's true that we must spend time accelerating. The problem with radial jerk is that the time spent doing that is time spent on a tool path that is neither linear nor circular, and since g code can only describe linear and circular movement, any time spent applying radial jerk will move us off the nominal tool path. The more time we spend "jerking" (the lower our jerk limit), the more we get off course. It is unavoidable.

To calculate a definitive jerk rather than ignoring it, we must take this into account. Not taking this into account is equivalent to ignoring jerk.

I wrote earlier "I think accepting this, and figuring out an acceptable way of handling it, is a big part of the difficulty in creating a jerk-limited trajectory planner." - and it seems I was right.

Please take a look at my post with the image from Wikipedia again. It is a good illustration of the problem.

That problem is not really any different than any TP deals with (at every g1 waypoint )
blending to tolerance by lowering the speed is the standard way to do this, its basically
the same with jerk factored in (though considerably more complicated)
With bounded jerk many profiles will actually be faster at a given following error budget.

Ok, so the algorithm should make the jerk limit an absolute priority then, and sacrifice feed rate to reach it. Got it.