I have no clue.

When I've built custom kernels, I'm pretty sure that the new kernel wasn't active until I rebooted. But rebooting after even dist-upgrade has just become automatic.

For unattended upgrades, you can disable automatic reboot. But then, I think there's risk that some upgrades won't take effect.

kexec is basically the same as a reboot, as far as userspace is concerned. Your sshd is going to go away.

Userspace sure, but what about underlying hardware? How will device drivers react if they come up and encounter hardware that is not coming out of a ACPI induced reboot? Will some devices and their corresponding drivers be OK? Or will the drivers panic when they encounter a device in a weird state?

I'm genuinely curious is all. At the time I was pursing this I decided it was going to get too complicated and that I had to live with a reboot.

This is a concern but it usually works for two reasons:

1. Most firmware is sufficiently broken that Linux drivers are already hardened against devices being brought up in arbitrary states.

2. kexec walks the device tree to shut down all devices before starting the new kernel. This usually gets devices closer to a startup state, or at least a smaller number of known shutdown states.

It's clever how one can restart sshd, after editing sshd_config, without losing the ssh connection. Very thoughtful, and counter-intuitive.