I encountered this problem recently, and after several days of debugging, I've discovered the issue and fixed it.
After installing Hyper-V Server 2016, use an offline tool (like, say, Windows PE) to mount the SYSTEM hive of the new installation, and change the DWORD ControlSet001\Control\BootDriverFlags from 0x04 to 0x1c. (You should probably change the ControlSet002 version as well for good measure, and you can bake the changes into your install.wim to avoid having to do this after each install.)
(Because of course it takes a week and a kernel debugger to figure out that it just requires a two-bit change in an obscure and thoroughly undocumented bitfield.)
The Windows boot loader uses built-in UEFI routines to find the Windows install, and loads the kernel and boot drivers into RAM prior to calling ExitBootServices. Once it has done that and passed control to the kernel, the kernel cannot access the boot volume unless the appropriate drivers are already present in RAM.
Here's the kicker, though: winload.efi is not complex enough to enumerate the hardware and determine what drivers are actually required. In older versions it would load only things set to Boot Start. However, loading extraneous drivers incurs a performance penalty, and as Windows started supporting more classes of boot devices, a better system was needed.
Enter the BootFlags value on individual drivers and the system wide BootDriverFlags value. If (BootFlags & BootDriverFlags) != 0, the driver will get loaded even if it isn't set to Boot Start. Each bit in the value is supposed to correspond to a different type of hardware, so the BootDriverFlags value sets which types of hardware can be booted from.
When this mechanism was introduced, Bit 3 was designated for USB boot devices, but booting from USB devices was unsupported in standard Windows. The Hyper-V Server 2008 R2 version added specific support for booting from USB by setting this value to 0x04, and this value has been set in every version of Hyper-V Server released since.
The general improvements made since then to support the Windows To Go feature mean that you don't have to use the boot-to-VHD trick recommended for previous versions of Hyper-V Server installed on USB devices. However, they also change the meaning of the BootDriverFlags value. USB 3 devices have been given a separate bit, and SD cards specifically have been given yet another bit.
In the 2016 version, this means that a value of 0x04 now enables booting only from USB2 disks that are not SD cards. All versions of Server 2016 except Hyper-V Server ship with the default value of 0x1c, which enables USB2, USB3, and SD card boot; however, the value of 0x04 is still set in Hyper-V Server, because it was added as an override in the image build process for the 2008R2 version. Instead of adding a feature, though, this value now removes it.
This explains why some previous solutions to this problem recommended disabling USB3 and booting from a USB stick instead of the SD card: this would force the category of the boot device to be something still covered by the now-more-limited definition of the "USB" bit in BootDriverFlags.