In fact adding a .control section to the eeschema generated netlist may raise some caveats.
It is largely untested in this environment (shared ngspice, simulation called by bg_run in a second thread) and thus bears some risk due to the multithreading involved. It may happen that the write command starts before the simulation has finished, then writing the old data.
It might be much better that the eeschema interface handles all the issues directly and care for thread synchronization. This has to be coded into eeschema. Therefore it is necessary to notify the KiCad developers and add these issues to the wishlist.