Scheduling influences on simulation outcomes?

Yes these are problems that can be solved if people care enough. It takes work and dedication to get it working with an existing codebase, and to keep it that way as people add new code (ask me how I know :) ).

On your last point you actually want fixed sized batches, for reproducabilitly. Then distribute each batch to a thread as the thread becomes free. That way you always do the same ordering of your floating point numbers ( (a+b)+c /= a +(b+c) in floating point maths). Think about summing elements in an array broken into chunks per thread, naively more threads would mean more intermediate values that need to get get summed up. With fixed sized blocks it doesn't matter whether someone runs your code with 1 thread or 100, the number of intermediate values is the same. So you get the same answer when the intermediate values get added up at the end.

On random numbers you would need each thread to have its own stream, plus someway to initialise each block of work to its own seed (not thread, again as the number of threads might vary between users).