Have you tried setting the Pawn Rotation variable only from the server? Without context, it appears it could be an issue where your client is setting it, then the client gets a replicated value from the server, rinse and repeat.
Along the same line of thinking, you’re setting the rotation locally, and then multicasting. The client and server will always have disparity here. In your example, the client sets it to where it is now, the server multicasts, and even with 20ms round trip delay (right in PIE a small amount of delay between the client and server is still present), by the time the client executes the multicast RPC, it will be setting it to the rotation that it WAS, not where it should be right now. Since the client and server will never have instantaneous communication, multicasts will always result in a client seeing things as they were, x milliseconds ago.
Your paradigm is not flawed, you’re doing things how you should be. You’re just not accounting for the delay between the client and server.
The easy approach is to simply not execute the multicast logic on the owning client, since they are already locally rotating. This will make the client see it as it should be, and the server/other clients will see the same but with a slight delay. On your multicast RPC, you could try only executing if the pawn is not locally owned.
The more difficult approach is to account for the client’s lag on the server, and sending the multicast to where the rotation should be in x milliseconds, where x is their one way trip time. This works for some games, and not others. Example, dodging. Client A fires at Client B, Client B dodges. If the server sets the position of Client B based on their lag, Client A sees at least some “teleportation” occur. In scenarios like this, a more refined approach is necessary, such as speeding up an animation by x milliseconds instead of simply setting the position. That, of course, comes with the drawback that higher latency players end up dodging much quicker for other clients, and can lead to “wtf?” moments.
Without context, it really looks to me like you’ve just got to account for the disparity between the rotation as it exists on the server and client. For now, testing the easy approach will take the least amount of time, and if it runs smoothly at that point you know this is the issue.