Regarding (/usr/share/doc/apt/examples/configure-index)

     AutomaticRemove "<BOOL>" {
        "Kernels" "<BOOL>";     // Allow removing kernels even if not removing other packages (true for dist-upgrade)
     };

I would also have another variable, with a digit argument,
e.g., "2" would keep the two latest unused kernels around.

In fact the default should be at least "1".

The new "0" policy, will certainly result in users needing to take their
computers to the repair shop, as all it will take is one bad kernel,
and the next time the user tries to boot... they will no longer be able to!

Yes, for the last few years it has not happened. But many of us remember
when it has. And we are thankful to the elders who always told us to
keep a few spare kernels around, that we can choose from LILO or GRUB,
in case the default fails.

(Sure: "Just boot from a thumb drive then." Well often those kernels
lying around one's house are already incompatible with the filesystem,
etc. and it takes an Internet connection to get new ones, but we can't
boot so no Internet, and we live on a mountain...)

There seems to be a misunderstanding on your side here - we always keep
at least 2 kernels and at most 3, just as we did before (it used to be a
maximum of 4 kernels for some time, but this broke stuff).

We keep:

- the currently booted kernel
- the kernel with the highest version number
- the kernel that was most recently installed

If those are less than 3 kernels, we additionally keep the kernel with
the second highest version number. This ensures a minimum of 2
constraints (and the maximum of 3 constraint there is new, well back).

We could generalize that code to always keep a custom number of kernels
but it surely complicates things a bit (because we do not always want to
keep at least 3 kernels, so we need a different fillup logic for such an
option).

I'd prefer sticking with what we have.

I also hope at least one "No available version in archive" version is
left on the disk,

# apt-show-versions -r -p '^linux-image-[0-9]+\.'
linux-image-5.10.0-1-amd64:amd64/unstable 5.10.4-1 uptodate
linux-image-5.9.0-5-amd64:amd64 5.9.15-1 installed: No available version in archive

Else if there is a botched update to all the updatable kernels, no good
one will be left!

retitle 979631 Document AutomaticRemove::Kernels facts somewhere
thanks
JAK> There seems to be a misunderstanding on your side here - we always keep

That is all great, but documented nowhere in /usr/share/doc nor any man
page.

Without knowing all that, users will worry or continue to rely on
programs like:

# cat bin/remove-oldest-kernel
#!/bin/bash -eux
# remove my oldest kernel to free disk space
# Copyright       : http://www.fsf.org/copyleft/gpl.html
# Author          : Dan Jacobson -- http://jidanni.org/
# Created On      : June 2007
# Last Modified On: Wed Apr 10 13:30:58 2019
# Update Count    : 126
ls -1 /boot/vmlinuz*
apt-show-versions -r -p "^linux-(doc|image)-[0-9]+\."
echo Remove \#...
set -- $(aptitude -F %p search ~nlinux-image-.........*~o)
echo [hit ^D to get out]
select kernel
do
   aptitude purge $kernel
break
done

Help. The kernels just don't go away:
$  apt-show-versions -r -p '^linux-image-[0-9]+\.'
linux-image-5.10.0-1-amd64:amd64 5.10.5-1 installed: No available version in archive
linux-image-5.10.0-2-amd64:amd64 5.10.9-1 installed: No available version in archive
linux-image-5.10.0-3-amd64:amd64 5.10.13-1 installed: No available version in archive
linux-image-5.10.0-4-amd64:amd64/unstable 5.10.19-1 uptodate
linux-image-5.9.0-2-amd64:amd64 5.9.6-1 installed: No available version in archive
linux-image-5.9.0-4-amd64:amd64 5.9.11-1 installed: No available version in archive
linux-image-5.9.0-5-amd64:amd64 5.9.15-1 installed: No available version in archive

(Kernels piling up is an aptitude bug, #902652.)