Ok, so in your case (and I bet Phantom Forces is the same) the problem is relatively straightforward.
Parts are grouped for rendering purposes into clusters, and a cluster has to be invalidated if parts inside it change other than CFrames being updated. I know that Phantom Forces does that all the time for the humanoids by animating the welds (which is bad for performance and I still don’t really understand why it does not use Motor6Ds but that’s a separate conversation); I’m not sure yet why your game has the same behavior - will look into it tomorrow.
Anyway, so what happens is that these clusters are put in a queue whenever they have to be updated, and we only process a few clusters from that queue to try to keep the game realtime. Unfortunately, this queue does not have a well defined ordering so if some clusters are constantly invalidated they can get “in front” of other clusters every time something changes so we end up constantly updating some clusters and never updating other. Which is why you’re seeing what you’re seeing.
It should not be hard to maintain a proper update order. I’ll look into doing this (not sure about next week, probably the week after that).