Not sure how to replicate this, but everything tests well on a locally hosted server (single player and multiplayer) with a copy of the world/modpack from our private server.

Copying this exact setup back to the server has an odd issue where the rails do not behave correctly when travelling west or north. East or south is perfect.

Since having to do both setMotion() and move() each time felt hacky anyway I'll look further into the reasons why it seemed I had to do so and try to come up with a better solution.

In the meantime you may wish to revert the last change, as even though the old behaviour was less consistent between high and low speeds it was more "workable" on a laggy server.

Fingers crossed I can come up with something that solves both issues.

Update: I may have found the cause!

Nothing to do with setMotion() and move() but in fact my change to use adding for the acceleration - I forgot to take the direction into account when adding the velocity, so the acceleration was always in the positive direction.

Stupid mistake, but easily fixed. I will do further testing to be sure but I'm pretty confident that is all it was.

Bit more complicated than I thought.

For some reason the motion.x (or motion.getX()) etc. parameters/methods always seem to go back to reporting a value of 1.92 after each tick. Not sure if that is from something I did or something in the movement code of entity, so I'll have to dig further. If I can find this out I think it will also help explain why I needed to use both move() and setMotion() too.

Bit more digging (let me know if you'd rather me not spam these threads, I figured it would be good to record what I find):

If I just use setMotion(), after a tick no matter what it was set to the next getMotion() call will return 1.92 for .x or .getX(). This must be coming from Minecraft internals so I'll dig further.

If I just use move() then getMotion() will record what we expect but the next tick it will have reset. This is hidden in our usage as the acceleration and speeds were so fast that setting them each tick feels pretty much the same as it would if it was receiving the correct "previous speed" anyway.

Okay turns out I was overthinking things and was actually closer to the mark with suspecting the acceleration. Basically the speedUpCart() method returns positive or negative depending on direction, but when passing its output to setCartSpeed() this is then multiplied by the direction vector again, negating this directional info.

Refactoring setSpeed() to take direction into account rather than recalculating it itself should solve this. Testing so far is positive but I just want to clean it up first.

Seems good!
Thank you very much for the detailed analysis!

Bit more digging (let me know if you'd rather me not spam these threads, I figured it would be good to record what I find):

Not at all! We really appreciate your help and work!