I’ve wasted over four hours into this just to see what this was, and if there was a fix. Let me show you what I did, what I found, and what I concluded. Brace yourself for the wall of text, or scroll down for the TL;DR.
After trying the OP’s original un-copylocked place and doing a lot of testing, I can say that including the OP’s findings (core engine bug, etc,) it happens no matter the framerate. I did everything that the OP did in terms of my own findings. Player Module checking, making sure stuff actually worked as intended with the regular vehicle controller script in the player, etc. Here’s what else I found.
So, in Studio, I copied the value printer and put it in a Server script for when the values update. I also included prints for when the vehicle controller module wants to update the ThrottleFloat, as shown here:
print(self.vehicleSeat.ThrottleFloat)
if -self.throttle ~= 0 then
self.vehicleSeat.ThrottleFloat = -self.throttle
else
self.vehicleSeat.ThrottleFloat = 0
end
print(self.vehicleSeat.ThrottleFloat)
(Yes, I programmed it where it forced the Float to be 0 if the throttle was 0. I didn’t want to see -0 in the prints 
)
During one of the oscillations, I captured this.
(Line 270 is the first print, Line 276 is the second print.)
The vehicle controller always sets it to 0 when released, which the OP says it does. But from what I can guess, the server doesn’t know that the throttle has been changed and it tries to catch up, which explains the oscillation.
A good thing to note is that the Server saw the throttle change to 1 at 0.197 seconds. At the same time in 0.198 seconds, the Client tried to fix that by setting it to 0. And that’s consistent; in the other oscillation prints, it’s to the millisecond plus or minus another millisecond.
Another thing to note is that assuming similar client/server framerates (60 plus or minus 1), it eventually catches up when the two framerates align like the OP said (to be fair, same in general with lag or without, but let’s focus on 60 frames since it still happens.) However, something else to add on: when I tap a key down again to initiate an oscillation while there’s already one going, it tends to either stop completely or halve/double its frequency.
One final thing: even if the player leaves the seat and when no other script - Server, Client, or Module - is updating the values, they will still oscillate.
I assume this is related to the Throttle and Steer property descriptions, where it says it must be set or it will refresh to 0, but that’s a bit confusing as well. Even when setting the Throttle or Steer in Properties, in simulated Server or Client, it does not refresh back to 0. The bug is part of the core like OP said, but I think it must be part of the C++ engine in specific. I say that because of all of my findings above, alongside the core Lua scripts (which was of interest to me too to check out) having absolutely nothing at all to do with Seats in general… or player movement at all.
I’ve done all that I could to see if there was some fix, even if it was a simple script or a replacement PlayerModule. Alongside what the OP did (which in turn I did), I made the VehicleSeat’s network owner to the client, I tested with a very old bus that I had in my models back in my 2010-2011 era (lol), everything.
i give up, gg roblox
The only two ways I could think of circumventing this bug both require quite a bit of work (subsequently I have not tried these.) You could probably have an input listener on the Client to send data to a Server script (by remote event) so the server can update the values accordingly, or just make something similar to the Endorsed Cars’ chassis or something like A-Chassis, where inputs are put straight to local scripts that update constraints or body movers. Nothing at all in common with the traditional OG Roblox chassis setup. Wonder why.
My assumption is that it has to do with networking thanks to replication and timing, but at this point I really do not know. All I hope is that this could be fixed because it could help a lot with some future projects I want to take on. It’s a bit of a tedious task to try to program stuff around this bug.
TL;DR: It’s a core engine bug like the OP said. The client can set Throttle and Steer with it replicating fine to the server. However, if you do it quick (tap) then the server won’t know it and will try to set itself over and over again. Even if the client taps again afterwards, it could either stop the oscillation, make it slower, or make it even faster. An old bug that never got fixed, so even Roblox themselves moved away from their old chassis in favor of some other overengineered ones, despite the fact that ThrottleFloat and SteerFloat are very good values to read from sometimes when making your own code.
That is, if those values were reliable in the first place.
Disclaimer: All of my findings were done in Studio and Studio only. This could definitely be different in an actual play setting with varying degrees. With that said, take my post and my findings however you will.
(All edits were small and were made to make this post more informative and easier to read.)
