Describe your suggestion

When A* expands a node it is guaranteed for this node to not change anymore, which means that at the time of calculating a movement, the information about the previous movement could be made available to the movement being calculated.
Similarly when while executing a path the whole path is know and could be available to the movements themselves.

Settings

This is a purely internal change and will not require any setting changes.

Context

Currently movements don't know anything about each other, making it impossible to do anything that requires
cross-movement interaction (e.g. post-smoothing descend-ascend chains) without completely overriding the movement and making it completely impossible to respect post-smoothing or other predictable changes in cost calculations while pathing. This might be relatively unproblematic with the small amount of predictable cost changes Baritone does, but there are already cases where Baritone could sometimes plan sprinting, if it had the information to decide about it.
Especially when it comes to parkour like it was attempted in #2142 the type and direction of the previous movement - or even better, the expected velocity - can allow cutting about half a second per jump for chains of long jumps, just because Baritone can keep moving (and knows it can do so in advance) instead of movement cancelling and accelerating each time.
Another possible usage of this information would be predicting post-smoothing of paths and adjusting movement costs to fit the smoothed costs, which would for example make the cost of a 2 or 3 block high fall movement followed by the same amount of traverses in the same direction be only the cost of the traverses (because it falls while walking) instead of the fall and traverse cost, as it currently is while planning, but not when actually executing it.

Note

As I don't know about potential performance penalties (though I expect the impact of simply providing the information to be really low) and I'm certain I have missed a bunch of counterarguments, feel free to tell me what I didn't know or think of and then close this.
Also it would be cool if @Zephreo could verify what I said about parkour.

Final checklist

• I know how to properly use check boxes
• I have checked if post smoothing could cause the need of negative movement costs
• I have edited the issue to point out how easy one can break optimality with this (though that does not automatically mean worse paths, paths can also become suboptimal by better paths becoming awailable)
• I have not used more than the provided amount of OwO's or UwU's in this issue.

It is true that this would be useful for chaining parkour jumps but this generally only occurs in created parkour environments and is unlikely to be used often in a generated minecraft world.

Can you make 1.17 baritone fabric it would really help.

Can you make 1.17 baritone fabric it would really help.

I echo what @PhoenixXKN said, however also don't just hijack issues like this that are about a valid suggestion.