So we’re not sidetracked by host-level concerns: the host is configured properly (as a Domain Member server), and I can think of nothing that is set on the host which would be relevant to a recent kernel change causing the VM to not boot.
Indeed, 5.3.18-lp152.8-default does boot properly when selected from GRUB. I can’t see any changes in 5.3.18-lp152.14 which should cause issues. And, very strangely, removing the .14 kernel does not lead me back to a working configuration. I’ve spent a few hours poking at why this might be, but have come up dry. I might be missing something when removing the package?
This does certainly look like a kernel issue, rather than the hyper-v package or some other package, though. If someone can validate that they can replicate the issue, or not, I’ll see what I can do to report the issue in an actionable way even if it involves installing each kernel individually and then going over the changes in the broken kernel by hand myself and then trying to rebuild a working kernel based on that.
As requested, here is the grub.cfg though there is nothing obviously amiss (though there are EFI logic changes):
Before: https://paste.opensuse.org/31731478
After: https://paste.opensuse.org/78860245
This latest testing was done on a throwaway VM, so I can confirm that it’s not some weirdness in an old VM. And at this moment, I’ve basically halted my 15.2 testing since it’s not currently in a bootable state on Hyper-V. 
If anyone else wants to try it out (it appears to behave the same on Windows 10 Client Hyper-V), here are some notes to get you pointed into the right direction:
[ul]
[li]Grab a 15.2 ISO that’s not too fresh, to ensure it’ll boot[/li][li]Create a Generation 2 guest[/li][li]Go into the guest’s Settings and make sure you’re using the Microsoft UEFI Certificate Authority for Secure Boot (this is the CA used for non-Windows signing and your physical PC probably ships with both CAs, which is why you’ve probably never noticed they have two before)[/li][li]Also in the settings, set the minimum RAM to 1536 and turn on Dynamic Memory (ballooning works perfectly fine, but the installation requires > 1GB)[/li][LIST]
[li]NOTE THAT SKIPPING THIS ONE WILL PREVENT THE INSTALL MEDIA FROM BOOTING, AT LEAST BACK TO 42.3 IF NOT EARLIER![/li][/ul]
[li]During initial install, have the Network Adapter set to Not Connected, so you don’t accidentally pull down the problematic packages on first boot; you can change it over once the installation process starts or after the initial reboot. You will, of course, have to configure the adapter after rebooting.[/li][li]For performance reasons, you might want to pre-create your virtual hard disk and select that instead of creating one in the wizard:[/li][ul]
[li]In PowerShell (may require Admin; not sure, as my creation script elevates), create a Dynamic disk with 1MB blocks: [/li]```
New-VHD -Path “C:\Path\To\Virtual Hard Disks\15.2 Test.vhdx” -SizeBytes 127GB -Dynamic -BlockSizeBytes 1MB
[/ul]
[li]For absolute best performance, pre-format your disk as ext4 and use your partitions in the installer (making sure to not reformat the ext4 / partition):[/li][ul]
[li]Create a GPT label and then create the following partitions:[/li][LIST]
[li]/dev/sda1: 500M EFI (Type 1)[/li][li]/dev/sda2: 2G Swap (Type 19)[/li][li]/dev/sda3: Remaining space as / using default type[/li][/ul]
[li]Format the ext4 / partition with Hyper-V-friendly options (the -G 4096 is the important option): [/li]```
mkfs.ext4 -G 4096 -O metadata_csum /dev/sda3
[/LIST]
[li]At the final pre-installation screen, set your elevator to noop[/li][/LIST]
A lot of those steps aren’t strictly necessary, but if you’re expecting to reinstall a few times the disk notes should provide a significant disk I/O improvement (on one very heavily loaded host with mostly Linux development VMs, we noticed disk utilization drop by nearly 30% simply by tuning the disk container and formatting properly, plus the noop elevator!), especially on non-SSD storage; you just need to mkfs the / in between each reinstall and the everything goes smoothly.