Simulation determinism/variability with the Neurorobotics platform has been investigated extensively and we know different reasons which explain why a simulation run by the Neurorobotics platform is not deterministic.
First, the current implementation of our Closed Loop Engine's control loop is not deterministic by design: the world simulation step (Gazebo) is threaded and runs in parallel with the execution of transfer functions. But we also have a deterministic version of the control loop (see $HBP/CLE/hbp_nrp_cle/hbp_nrp_cle/cle/DeterministicClosedLoopEngine.py) and you should be able to use it in the future with a simple change in the experiment configuration.
Second, the asynchronous nature of ROS and its current integration with transfer functions make them non-deterministic: there is no guarantee that the same ROS message will be available at the exact same time by a transfer function, from one run to the other.
Eventually, Gazebo has its own source of non-determinism as its publishing rate of images is not deterministic. A patch is available (see https://bitbucket.org/osrf/gazebo/issues/2293/non-deterministic-image-render-frame), but it is not part of the NRP yet.
For each of the aforementioned issue, there is a solution and an epic has been written to address them all. The pace at which we will tackle non-determinism in NRP depends on our priority sort and users' requests.