“80+deb9u6” is the version of the
linux-latest source package; this builds meta-packages which pull in the current kernel package for each platform, for example
linux-image-amd64 which you have, and are versioned with the base kernel version, resulting in 4.9+80+deb9u6.
“4.9.0-8” is the ABI version of the kernel; it appears in specific kernels’ package names, e.g.
linux-image-4.9.0-8-amd64. The version represents the base number of the kernel series, and a number which is bumped every time the kernel ABI changes in an incompatible way — in terms which matter to users, whenever out-of-tree modules need to be recompiled.
“4.9.144-3.1” is the package version of the kernel. This follows the standard Debian versioning scheme: 4.9.144 is the upstream kernel version, which you can match up to upstream kernel releases, and 3.1 is the version of the packaging. The first package of a given upstream version is normally given version 1 of the packaging, then every time a new package is uploaded (without changing the corresponding upstream), the packaging version is incremented. You can see the details of what changed in each version in the Debian-specific changelog.
All this combines to provide a number of features which are useful for end-users:
- users can install an architecture-specific meta-package, such as
linux-image-amd64, and be sure they always have the latest available kernel package — currently the meta-package is version 4.9+80+deb9u6, which pulls in
linux-image-4.9.0-8-..., and when the kernel version or ABI version change, a new meta-package will be uploaded;
- new upstream kernels (or Debian patches) which don’t change the kernel ABI in a backward-incompatible manner won’t result in unnecessary package churn or local rebuilds (for out-of-tree modules);
- kernel ABI changes which require them will result in module rebuilds, so installed modules are always available and installable into the running kernel (barring bugs).