Looking Ahead: Linux Kernel 6.12 Includes IO_uring Async Discard -- Will this impact Host and VM Setup Best Practices?

[SInisterPisces]

N.B.: The current version of Proxmox is built on top of the 6.8 kernel. This won't be an issue in the real world until Kernel 6.12 becomes the Linux LTS kernel, at least. I'm not sure when Proxmox will switch over, but probably not until sometime in early 2025 (Proxmox 9?)...
Sources:

• https://www.phoronix.com/news/6.12-IO_uring-Async-Discard
• https://github.com/axboe/liburing/wiki/What's-new-with-io_uring-in-6.11-and-6.12

Quoting from the Phoronix article:

O_uring async discard support was sent in as one of the feature pulls aiming for Linux 6.12. Applications can now issue async discards rather than blocking sync ioctl discards. On slower storage devices this async discard support can make a big impact on performance with cases going from like 14K IOPS with sync discard to around 56K IOPS with async discard.

From the liburing github:

Support for async discard requests
Linux has a block ioctl to issue discard requests to a device, but like other ioctls, it is fully synchronous. This means that it'll block the calling thread, and to achieve any kind of parallelism for discard operations, many threads must be used. Needless to say, this is inefficient. 6.12 adds support for discard operations through io_uring, in a fully async manner. Performance details on a basic NVMe device provided in the below linked merge commit. Since then I did some testing on another device, and not only does async discards use a fraction of the CPU compared to an equivalent number of threads to retain the same number of inflight IOs, it was also 5-6x faster at the same work.

So, this sounds excellent, and will be available in Proxmox someday.
Question: How will this impact IO_Uring settings in Proxmox VMs, if at all? The default is to use io_uring for virtual disks, so I assume the VM will just pick up whatever performance gains might be associated with async discard (without us having to change anything) when a TRIM operation runs inside a VM, but is it more complicated than that?

What about the host? I'm running a ZFS-based Proxmox host, and autotrim is disabled by default on my NVME mirror (boot pool/VM storage). My tl;dr memory on why this is the default behavior is that enabling a scheduled synchronous (blocking) automated disk operation (TRIM/discard) on an active Proxmox host will absolutely shred guest disk performance.

Does the introduction of async thus mean that we'll now (or eventually) want to move to autotrim being ON for the host? Or at least, that we'll want to start manually turning it on if we know our storage media actually correctly supports TRIM/discard operations?