Never experienced such issue with ROS config on reboot, I think @rextended mentioned only in case of self-modifying scheduler config prior reboot. Regarding containers, yes, when I was experiencing issues on some prev. ROS versions they were killed upon shutdown, not terminated, then some services (like Pi-hole) which can write something into their own DB are not gracefully stopped because they did not intercept TERM signal to finish operations and it can result corrupted service DB because service was killed in the middle DB write transaction. Never tested if this behavior regarding containers was changed on some later ROS ver. because I have script that handles that.
I don't think that's the case. Config seems to be flushed on reboot, and in fact the reboot waits for all processes to terminate gracefully up to a time limit.
I think this effect (and many others around scripting) is because many commands are issued, but then completed asynchronously. In these cases, the next commands may be executed before the results of the previous ones are affected.
Still if all is gracefully terminated async command execution should not be issue in case of ROS config write before shutdown (not sure if @rextended actually had this issue or it is a speculation).
Regarding container processes, I'm quite sure that they were not gracefully terminated, or there was short timeout wait until are stopped and killed if not stopped in timeout period, it was easy to notice, when stopping them manually, time to take to reach stopped status was longer than ROS shutdown when containers are started. Again, not sure if this behavior regarding containers is still actual in recent ROS versions.
I'm now in temptation to write script that runs in container which intercepts TERM signal and writes some file on FS when signal is intercepted (with some delay) to check what happens on ROS shutdown. 
I'm quite sure that the system waits. I used to have a bug where ssh tended to hang on reboot and the system waited for (I think) exactly 60s before killing it. Also, if you're logged in via ssh when rebooting, you get the correct "the system is going down" termination message.
What I can easily imagine is that the process that's doing the async work and the process that maintains the config db are separate. Both get the term signal, and because the config writer has nothing to write, it shuts down immediately. By the time the async job is finished there's no one to write the config.
(I have no idea about the container aspect.)
That shuld be only case if reboot/shutdown command is called prior config change command, if separate async process is received config change, it's operation should be completed when is gracefuly is terminated, as I see it:
/some_config_change_cmd1
/some_config_change_cmd2
/system/reboot
when commands prior reboot does config change in async process(es), such process(es) received action to change config before it will receive TERM signal and it should complete before reboot it are gracefully terminated. If such commands are performing some heavy operations and sending write config to separate config writer process at end of operation execution, IMO it is a bad flow, better to introduce revert config change in case if something fails than wait whole operation to finish. Other solution could be that config writer process is always terminated last.
I'm not a fan of the scripts that update scheduler, as that is a config change. While yes it should work, even in best case, its flash write and config change. Basically I feel like there always is some conditionals/on-error and/or correctly waiting for async commands by checking status, not just delay that accomplish the same thing with using scheduler as a work queue from other scripts.
And here we're walking about checking for firmware. Which is "async" command, and in particular the check depends on internet to know versions. So you do have to be careful with check-for-updates and routerboard/update to loop on the status of the async version check. It often the :delay may not be enough and/or some unhandled cases if you're not careful with the "async" commands.
I do not understand original problem very exactly, but to answer the "Press any key" scheme... there is /terminal/inkey timeout=60s. So something like this works:
{
:put "will do the thing in 10s unless you press a key";
:local hitkey [/terminal/inkey timeout=10s];
:if ($hitkey < 65535) do={
:error "cancelled by hitting key (key: $hitkey)"
} else={
:put "do the thing (key: $hitkey)"
}
}
Yes, but that requires the console to be the controlling TTY of the script. That would work when you start the script from the console or from a terminal window.
But he starts the script from the scheduler. In that case, there is no controlling TTY (the script is running "in the background") and you cannot get terminal input. Same when the script would be started from some event like establishing PPP or issuing a DHCP lease.
I think /terminal/inkey will not work for script in non-interactive terminal when executed from scheduler, other solution can be that will avoid changing scheduler config is when script checks if fw. auto-upgrade requires reboot it writes to file on flash as a flag before reboot so that for next boot will be checked if exists to avoid reboot again if auto-upgrade is still present (which means it failed), if auto-upgrade reboot is not present deletes file for next upgrade reboot. In this case script will no longer perform reboots when fw. upgrade fails until is resolved manually (upgrade and flag file delete).
Remember the simple security check:
NO LINK on any ethernet (or sfp) = NO Reboot...
OBVIOUSLY, wireless could have been used to upload the update...
But to be safe, it never goes into a boot loop if the Ethernet is disconnected.
It allows you to log in via Wi-Fi, or connect the cable AFTERWARDS, and disable the scheduler...
There are of course many conditions that you can use, depending on the type of device.
And when it is not one of the toy devices of course you would normally use partitioning, and a simple off-on-off-on power sequence would bring it back to an earlier state.