I definitely see the point of having control over the randomness, but I personally think it should be external to the protocol.
In my programs, I have a configuration parameter that sets whether the program is deterministic or not. I'm nitpicking, but a random seed implies a particular implementation, but setting "determinism on" is more general.
Don
c) In subsection 6.2.2 Regression, I would suggest the addition of: get_random_seed, set_random_seed Both commands are already implemented in GNU Go and I assume most, if not all engines would introduce a degree of randomness based on a seed. An engine that does not use pseudo-randomness (?) should output 1 for the get_random_seed command and save the parameter of the set_random_seed command in an otherwise unused variable, returning it if requested by the get_random_seed command.
I'm sceptical about this. First because I doubt that all engines use a scalar random seed like GNU Go does. Second because programs with a more sophisticated time handling than GNU Go probably has other, hard to control, sources of indeterminism.
Furthermore I'm not sure what purpose you see for these commands. Apparently you intend them for regression use but for reg_genmove it's advisable to turn off all random variations anyway, in order to avoid meaningless regression fluctuations.