In most game engines, physics objects live in their own world, and are connected to game objects through some special logic, responsible, for instance, for copying transformations and notifying about events like collisions.
Your case sounds like it requires multiple physics worlds. Most physics engines will allow you to do that, as they are designed in a modular way to be added to any game engine. For instance, in Bullet you'd create multiple instances of btDiscreteDynamicsWorld.
As long as the physics engine is deterministic, you should be able to maintain a "real" physics world, plus a bunch of "simulation" ones. In order to predict the outcome you'll need to:
- Step the physics world as far as required. You need to do it by calling the step/update function multiple times with small time deltas. Otherwise the results won't be stable. 60 fps is ideal, but can be expensive. It depends on whether you can afford a hitch while you predict the result.
- Once you have the results, you can connect the physics world with your game world to display them. You'll have to write some special glue code so you can walk through all the objects in your game and connect them with the appropriate physics object (probably based on name), and then transfer the transform and any other info required.
- Finally, once the player chooses an option, you simulate it using the "real" physics, in real time.
- For the next choice, you'll have to destroy the simulation physics worlds and create new ones, up to date.
Unfortunately, I'm not sure how you'd do this directly in Unity. Engines tend to be optimized for the common cases, and having multiple physics worlds is unusual. The advantage is physics engines tend to be written in a modular way, so this should make it easier.
One thing to keep in mind is that if the final outcome depends on how objects react after collisions (e.g. exploding), then you may need to duplicate your whole game world. The only alternative to this would be implementing undo functionality, so you can rewind your world.