The backends each have their own focus, and are not at parity with each other yet. So your choice will depend on the kind of game you’re making. Here’s a quick rundown:
Network Prediction backend: This is the most flexible of the backends, and where Mover started. It makes no assumptions about actor composition, so you aren’t limited to traditional upright single capsule movement. You can use choose a fixed tick or independent ticking simulation (similar to CharacterMovementComponent’s networking). One of the biggest challenges is working with simulations that run very early in a game frame, before any of the game world’s tick phases run. This can make it difficult to integrate with other UE systems, and we haven’t solved all of these problems yet.
Network Physics backend: this makes use of UE’s Chaos Networked Physics system. This is a good choice if your project calls for interaction with physics objects, whether networked or not. Mover support is largely limited to upright capsule characters so far. This backend is undergoing a lot of internal development, so we hope to expand the types of objects that can be simulated in the near future, and its performance and efficiency is steadily improving. If using networked play, you must use a fixed physics sim tick. For single-player, there is no ticking requirement.
Standalone backend: this is for single-player games only, and has less overhead than the others. It breaks Mover-related work up into phases (input production, simulation, results application), with 2 goals: allowing some of that work to be performed asynchronously on worker threads, and allowing the phases to be ordered with dependencies of other systems like AI or animation. It also makes no assumptions about actor composition, similar to the Network Prediction backend.