An enhancement could be for an automatic reboot after 1 hour to the previous slice if the upgraded slice is not confirmed as being successful from either the GUI or a CLI prompt. This would be very useful to anyone supporting remote systems as downtime would be limited to 1 hour following a failed upgrade.
That would be a nice thing, but would only work if the OS on the new slice is actually bootable. I guess that could still catch some application issues, e.g. if the system booted OK but some firewall rules startup/VPN links/road warrior VPN server… did not come up.
If it got some issue booting then any process that monitored things checking to see if success is confirmed by someone/something, would not be running. I can think of 2 cases like this that have happened to me - some dev snapshots that were missing a kernel, and hardware that worked with FreeBSD 8.3 + pfSense 2.1.n but did not boot FreeBSD 10.1 + pfSense 2.2.n - in both these cases the system was sitting at a console boot prompt of some sort and unable to proceed. I always have at home or at my local office an example of every hardware combination that is installed somewhere remotely. Then I can do local upgrades first and know that all my hardware combinations are at least bootable.