A rather curious bug i was unable to find any previous reports on, except this one. The OP concluded it was a bug in his code, but after thorough testing i firmly believe this is a physics engine bug. It seems to break the behaviour of VectorForce or Torque constraints (others may be equally affected) when their NetworkOwnership is switched from Server to Client, resulting in sudden angular or linear acceleration. I have provided a video with all of my experiments below, along with the place file.
The video showcases a series of simple experiments, starting with each part behaving correctly while its NetworkOwnership is set to Server, and then breaking as soon as set to Client.
The issues you’re seeing are a consequence of the physics replication frequency being lower than the simulation frequency. The physics engine simulates at 240Hz, but physics replication (sending the positions and velocities of parts, updating constraint properties, etc.) occurs at a lower frequency (for the sake of discussion, let’s say it’s 30 Hz, but in reality it is tuned based on available resources). What’s important is that physics simulation frequency > physics replication frequency.
Let’s consider the buoyancy simulation you provided (super cool btw!). Since the script that controls the buoyancy/drag forces is a server script, the server is in charge of setting the Force of BuoyantForce and DragForce. When the client owns the part, the server only gets sent the part position/velocity (PV) every 8 simulation steps (240/30). The server interpolates (basically makes an educated guess of) the PV data for the other 7 steps. The buoyancy/drag forces get calculated using the interpolated PV data, and then are sent back to the client (also at 30 Hz), so there’s latency at both sides: sending the PV data to the server, and sending the updated forces to the client.
Unfortunately, this is where it gets technical. The systems you built are all examples of feedback control systems, and determining whether a controller is stable requires applying the Nyquist stability criterion. Ultimately, the results you show illustrate that the sampling frequency for a client owned, server controlled part is too low for these systems to be stable.
You can get around this by making sure that the controller and simulator are the same (either both on client or both on server). You can put the controller code in a ModuleScript so that both client and server have access to it, enable the control logic in a Script if the part is owned by the server, and enable the control logic in a LocalScript otherwise.