Does enabling huponexit ensure background jobs receive SIGHUP on shell exit, or does disown override it?

When migrating a small application without downtime using Bash, a common pattern is to replace the current shell with a new binary via exec while trapping SIGTERM and SIGHUP to perform cleanup and relaunch the service.

The reliability of this approach hinges on how background jobs are treated when the parent shell exits. Bash's huponexit option controls whether the shell sends SIGHUP to its jobs, but the disown builtin can remove jobs from the job table, potentially altering signal delivery.

Because the interaction between huponexit and disown varies across Bash versions, it is unclear which setting guarantees that a long-running child process will continue to receive (or avoid) SIGHUP during a seamless restart.

Does setting huponexit alone ensure that background jobs receive SIGHUP on shell exit, or does prior use of disown nullify that effect?

Can a migration script rely on the default huponexit state across Bash 3.x to 5.x to predict job-signal behavior?