[Magisk] pndwal:
Well here's the 'why' anyway; thought I'd provide a summary -

For anyone interested in both Android and Magisk evolution to modern 2SI boot protocol...

SAR

The first major departure from (Legacy) Ramdisk Android boot type was (Legacy) SAR.

This was introduced largely to accommodate A/B partitioning & seamless updates while conserving / reallocating memory resources, and changed Legacy Ramdisk's initial rootdir from rootfs to system.

A/B SAR eliminates recovery and cache partitions and halves the size needed for system by shipping factory preoptimised system app .odex files, which formerly took up ½ /system partition, on inactive /system_b partition and moving them to /data on first boot... An updated .odex file would have been installed to /data in any case after first Google Play update for each system app which means original .odex files in system are soon rendered redundant and actually remain unused for most of the life of the device...

In practice all this means that the same effective capacity for all active partitions, even with Bootloader, Boot, Radio, Vendor & System duplicated in a & b, is achieved with an increase of just under 1%, or 320 MiB on a 32GiB device, making A/B SAR a very cost effective proposition...

2SI

Since initial rootdir was changed from rootfs to system w/ introduction of Legacy SAR, a problem was created for prospective new Dynamic Partitioning scheme(s) for Android 10+. This is because the Linux kernel can't understand this new partition format and is unable to directly mount system as rootdir. In other words, a solution was required to support logical partitions as the kernel cannot mount the super blocks directly without userspace support.

2SI was/is the new solution designed to overcome this obstacle by having the kernel boot to initramfs as (initial) rootdir and execute /init in rootfs, just like Legacy ramdisk devices did.

The difference is that instead of initramfs booting Android, init in rootfs mounts the system partition and uses it as a new (Final) rootdir (in SAR, /system is Initial rootdir), allowing userspace to handle the rest of booting including deciding whether to boot into Android by executing a second-stage init (/system/bin/init), or into recovery. (In A/B w/o recovery partitions, method is officially called USES_RECOVERY_AS_BOOT; Some A/B devices have recovery_a/_b partitions (OnePlus 8T?) and only use the boot ramdisk to boot into Android as do A-only 2SI devices).

-------​

So basically boot to initramfs was replaced with System As Root w/ SAR in Android 9 (7.1 in the case of first Pixel), booting directly to /system... Then boot to initramfs was restored w/ 2SI in Android 10!... This explains why Google doesn't consider 2SI true SAR...

John Wu Android boot refs:

- Android Booting Shenanigans

-"2SI is a NIGHTMARE to work with, so yeah...."

FWIW, the issue where previously patched boot image becomes incompatible and Direct Install breaks seems only to affect certain devices, notably OnePlus...

Perhaps the issue is reverting either AVB stripped flags, the modded fstab (file location in the ramdisk, fstab copy in /vendor/etc., the way OEM's like OnePlus implement the Device Tree Blobs / Device Tree Blob Overlays containing fstab etc may cause problems) or some other variable...

https://source.android.com/devices/architecture/kernel/mounting-partitions-early

Could be some module or mod?

Never saw that... PW