I'm not fully seeing what the issue is with the kernel, and I don't see how it could be anything in your init either since my .zip flash doesn't touch any of that aside from your system/lib/modules. The only thing missing is the scsi_wait_scan.ko driver and i'll upload that to github and you can stick it in system/lib/modules and see if it makes this "scsi: killing requests for dead queue" go away and allow the disk to mount, but what it appears to be in the logcat output is device names being different than expected with the mount scripts for attached devices. I just can't really see the diff in ezT20 as his sources appear to also be based off a501 and a500 code drops. This is definitely odd..
scsi_wait_scan.ko download - remount /system rw and place in /system/lib/modules reboot with the alpha-4 kernel, and see what happens.. (probably nothing, i have never knew of any system depending on this module..but it is worth a shot)
This should make ezT20 and my zip content layouts the exact same other than his nfo.prop sourced file.
Do you think that NTFS RW support could be conflicting with the acer ufsd module somehow? I can't find a single instance of ntfs or ufsd either one in your dmesg log. But in logcat the vold is saying no such device for the usb_storage at /dev/block/vold8:1 makes me wonder if the device is for some reason being recognized as a diff device
can you try to manually mount the ntfs partiton and see what happens? did you say that insmod /system/lib/modules/ntfs.ko is giving an error? is it loaded when you lsmod|grep ntfs ? makes no sense since the init scripts aren't touched when you flash this kernel, and the modules are the exact same name and location as what you was using before, if you was using ezT20.