[qwery]

PhysX itself (assuming Unity still uses PhysX, but any major physics engine will be the same) is unlikely to be your problem, although it is possible that Unity compiles it with undesirable optimisations, or some aggressive multithreading strategy, etc.

In any case, it's quite likely that the physics simulation is not being initialised with identical state on each instance, so the physics engine -- even if it claims to be deterministic -- cannot be expected to arrive at the same solution across instances. From the scripting layer atop Unity (et al.) you are essentially out of luck. You don't have the requisite control/access to guarantee the simulation input is consistent.

To expand on the "quite likely" variance in the simulation input, there's an unending list of possibilities, so just a couple of points: Unity is really really big and complicated. The physics engine in Unity is not primarily there to be a FEATURE: physics engine. It's a general purpose collision system, and it's fundamental to Unity's whole world/scene/components. It's always running. Stuff that has nothing to do with what you see as your simulation can affect your simulation.

My unopinionated advice is: read Glenn Fiedler's classic networked physics articles[0].

My opinionated advice is: you're making a game where the physics is the whole game. It's also a very nicely contained problem space. Write your own physics simulation. It's gameplay code. Also, typical rigid body physics engines certainly can do a billiards sim, but they aren't actually that good at it.

[0] http://gafferongames.com