This very same problem has stumped me many times before! You are correct in that this is happening exactly because of the VelocityOrientationProperty using the position to compute the orientation. Intuitively, you’d think, why shouldn’t CesiumJS just keep the last known orientation if there is no change to the position?
But herein lies a problem, and it has to do with derivatives and inflection point stability. Basically, imagine your car is oriented 90 degrees when moving from A to B, but orientated 45 degrees when moving from B to C. When the car is stopped at point B, should it be facing 90 degrees or 45? Well, that depends on the last known orientation, which is going to be different depending on whether you’re playing the timeline backwards of forwards! So it’s this inconsistency, that there’s no one correct value, but that it depends on what you were doing before, that’s why Cesium avoids it by defaulting to the default orientation.
With that said, the way I’ve worked around this is to make the orientation a CompositeProperty (https://cesiumjs.org/Cesium/Build/Documentation/CompositeProperty.html?classFilter=CompositePro). In the intervals when the vehicle is moving, its value is the VelocityOrientationProperty. In the intervals when it is not moving, it is a constant orientation, facing wherever direction I (or the developer of the app) deems to be the correct one (usually the orientation it was at right before it stopped). It definitely helps to write some boilerplate code to make this more automatic if you’re doing this for several vehicles.
This is something I’ve been wanting to write a tutorial on, or improve the Cesium built in mechanisms for. Pull requests or suggestions would be definitely appreciate here! I hope you find this helpful.