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.
An update related to this thread.
I worked a bit on a script for what I imagine was your demand.
No ready yet, but is much better than my first version.
P.S.: I would like to use critical topic for logging, but its no possible.
Or at least I don't know how to do.
The "Magic" is on grep.
grep got into list of supported commands just in 7.13, and correctly working on 7.14.
# RouterOS - Script "rebootForRouterBOARDFirmwareUpgrade"
# Tests if device needs reboot to apply routerboard Firmware Upgrade.
# Can do the reboot, or just do a forced warn with a login note.
# The correct functioning of this script depends on:
# - RouterOS Version 7 earlyer then 7.13/7.14 (uses grep command).
# - RouterBOARD firmware auto-upgrade feature being enabled.
# Following variable will define if reboot should be done, or just warn.
# If you really want that this device reboots to apply firmware upgrade you neet to set this variable as "IAuthorizeToReboot".
:local actionIfDetectRebootIsNeeded "IAuthorizeToReboot";
:local currentScriptName [:jobname];
:if ([:grep script="/system/routerboard/print" \
pattern="Firmware upgraded successfully, please reboot for changes"]!=0) do={
:global rebootForRouterBOARDFirmwareUpgradeIsNeeded true;
} else={
:global rebootForRouterBOARDFirmwareUpgradeIsNeeded false;
}
:if ([/system/routerboard/settings/get auto-upgrade] = true and rebootForRouterBOARDFirmwareUpgradeIsNeeded = true) do={
:if ($actionIfDetectRebootIsNeeded = "IAuthorizeToReboot") do={
:log warning "RouterBOARD firmware was upgraded by $currentScriptName script!"
:execute { /system reboot; }
} else={
:log warning "System note was overwrited by RouterBOARD $currentScriptName script!"
:execute { /system note set show-at-cli-login=yes show-at-login=yes \
note="RouterBoard Firmware needs attention!"; }
}
}
I'd argue this is a bug that the new about support did not make it to /system/routerboard. 
In some case, the "red things" can be read from a script using get about on the item, which has the text. But there is not about attribute in the /system/routerboard. For example, I have an LTE interface without a SIM card. In WinBox, there is a red "SIM not ready" (which is correct, there is no SIM here).
But it can be read like:
:put [/interface/get lte1 about]
# SIM not present
The same is not true in /system/routerboard, there is not about attribute on root or on ./settings sub-path.
Your grep trick is neat, and I think your right that's the only way to know if a firmware upgrade is pending - comparing version only could trigger the request, not confirm is was pending reboot.
Now given other stuff requires a reboot (IPv6) to change settings, IMO it be better if there was some "global" flag to know if anything required a reboot. Perhaps some /system/watchdog read-only attribute that tracked if reboot was needed, or similar common place to check... Since parsing the about (or grep ... print) is not ideal since some re-worded message and check fails.
It seems to me like you mean "later than 7.13/7.14".
I believe "newer then" is more adequate.
That is your script, so of course you choose which adjective (and superlative) you like better 
, if you had written older I would have suggested newer, since you wrote earlier, the antonym is later.
Still then is not the same as than. 