Wrong sorting order of kernel versions

I sent an email about this, but here is definitely a better place.

Distribution (run cat /etc/os-release):

NAME="Pop!_OS"
VERSION="22.04 LTS"
ID=pop
ID_LIKE="ubuntu debian"
PRETTY_NAME="Pop!_OS 22.04 LTS"
VERSION_ID="22.04"
HOME_URL="https://pop.system76.com"
SUPPORT_URL="https://support.system76.com"
BUG_REPORT_URL="https://github.com/pop-os/pop/issues"
PRIVACY_POLICY_URL="https://system76.com/privacy"
VERSION_CODENAME=jammy
UBUNTU_CODENAME=jammy
LOGO=distributor-logo-pop-os 

Related Application and/or Package Version (run apt policy $PACKAGE NAME):

kernelstub:
  Installed: 3.1.4~1674849051~22.04~851230b
  Candidate: 3.1.4~1674849051~22.04~851230b
  Version table:
 *** 3.1.4~1674849051~22.04~851230b 1001
       1001 http://apt.pop-os.org/release jammy/main amd64 Packages
       1001 http://apt.pop-os.org/release jammy/main i386 Packages
        100 /var/lib/dpkg/status

Issue/Bug Description:

The bug is in how kernelstub determines the "latest" kernel version.
It uses the Version class from the debian.changelog package:

from debian.changelog import Version
[...]

for version, option in opts.items():
    # If option is not complete, skip
    if 'kernel' not in option or 'initrd' not in option:
        continue

    # If this option is newer, store this option and continue
    if latest_version is None or Version(version) > Version(latest_version):
        latest_version = version
        latest_option = option

But "man linux-version" says cruelly but clearly:

   linux-version operates on Linux kernel version strings as
   reported by uname -r and used in file and directory names.
   These version strings do not follow the same rules as Debian
   package version strings and should not be compared as such or
   as arbitrary strings.

This has bitten me as follows. I had not read "man linux-version" and
I had relied on reading the kernelstub code; so I assumed the debian
package sort order. I made a backup of my kernel image, module
directory and initramfs and named the backup something like

/boot/vmlinuz-6.9.3-76060903-generic~itz20240731

and mutatis mutandis. This was specifically tailored to fit one of
the edge cases in the debian sort order, because it actually sorts
before

/boot/vmlinuz-6.9.3-76060903-generic

But the kernel order has no such edge case, and so in the kernel order
my backup version string counts as latest -- and will be used as the
implicit version if "-k" is not passed to update-initramfs, which was
very contrary to my intention.

Expected behavior:

kernelstub should use linux-version to determine the kernel version order, or use equivalent code, avoiding the code from dpkg, which implements a different (but similar) order.

Other Notes:

I should add that there is a higher-level bug that led to all this:
namely, PopOS (or Ubuntu?) ships package upgrades of the linux kernel
image packages without increasing or modifying the kernel version
string. This means if the updated kernel is broken somehow for me,
and I have no backup, I'm stuck. Possibly badly stuck if the breakage
affects networking.

This was the reason I started making the ~itz2024* backup kernel copies.