[OnePlus 8 Pro  ROMs, Kernels, Recoveries, & Other ] tbalden:
No worries. Thanks for getting back to this. :)

I'll try to sum up stuff. We have a better situation then, as you found ways to still get to a working state when you experienced the issues with the screen.

As for the backup, Google's backup could be enough, if you have it enabled to back up into google cloud. I usually restore all my play store apps/calls/SMSs, contacts, with Google's restore feature. You can check whether it has completed in System settings / Backup usually. If you have non Play store apps, then that won't have this kind of backing up. I usually get them reinstalled if things go bad on my tests and I need to factory reset.

So about testing, I'd be interested if the build. 2.2.0 alpha2 without the cleanslate features produces the same issue on manual Restarts, as with alpha3.

installer for 2.2.0 alpha 2 - no cleanslate features https://androidfilehost.com/?fid=10763459528675560161

2.2.0 alpha 3 - cleanslate features added https://androidfilehost.com/?fid=10763459528675560206

BUT Before installing, to get back to stock easily, I recommend to do the Magisk rooting on a stock boot image, which you probably already done to install stuff.

Grab that boot image from sdcard, to your PC. That boot image you can restore anytime later, by simply flashing with fastboot from a PC.

So to restore to a stock rooted one you need: fastboot flash boot magisk_patched.img, then boot. After that you can again reflash Omega installer zip or the kernel that you want to use.

So when testing, and the backup of that stock magisk patched boot image is already on your PC, you can safely start with installing the 2.2.0 alpha2 with FKM or EXKM. After that...

Please try the restart thing a few times on Alpha 2, and if it is problematic, please try to capture logs. As the phone is not actually rebooting, live 'dmesg' kernel log is what we should look at, while the issue is happening.

So if the issue is just happening, try to connect with adb, when it happens, or a bit after. The commands I detailed below could just work out. This also already should work before you enter the Decryption code, - so basically as soon as the phone starts to boot, at some point the USB / adb connection will be available (without decryption too), even before the decryption input screen. So when USB/adb can be accessed (Windows usually signals this with a sound as well), you can use adb shell command.

adb shell
su
dmesg > /data/local/tmp/log1.txt
exit
adb pull /data/local/tmp/log1.txt

If alpha 2 is not problematic, then please move on to Alpha 3, and after flashing, please try the same restarts, and capture the logs just when you have the issue with screen not coming on, as soon as 'adb shell' can connect to your phone from the PC.

If you have the logs, please share them here and describe which kernel version you tried, and what you experience while taking the log.

That's all! :)

If the kernel would do random reboots, that would be another case again, then we would need a different approach. If there will be random reboots, I can explain how that can be tried to investigate by getting the so called console-ramoops files (which is a special copy of a RAM area which contains kernel logs from exactly the time when the 'oops' happens, that's why it's named RAM-oops file :))