It appears as if the decision has been made to keep config group parameters immutable throughout a simulation run. I assume that this is for consistency reasons, presumably because the controler reads config information only once upon startup such that later changes may not automatically carry through to the simulation logic.
This obviously leads to problems for any algorithm that changes config parameters during the simulation. Optimization is one example, calibration is another one.
From what I see, such algorithms would now have to duplicate the config container, to not lock the duplicate, to then make within-simulation changes to the duplicate, and to re-build the relevant objects (in my concrete case, ScoringParameters) from the duplicate.
Apart from being awkward (I cannot find a "deep copy" function in the config), the original design of locking the config would still be invalidated, just now the other way around: simulation parameters are changed, but the config is not updated.
Locally replacing ConfigGroup.java by a c&p version that does not have lock is becoming a tempting option...