To what should be ascribed a discrepancy in the bcdedit values?

0x17000077 is the type of element in the BCD store. This 64-bit value is decomposed this way: the first highest nibble (0x1) indicates the class (here a "library"), the second one (0x7) is the format used for representing the assigned value (a list of 64-bit integers), and the lower 24 bits (0x000077) is the subclass (specific for that "library" class, here "AllowedInMemorySettings").

So this indicates that the value given to AllowedInMemorySettings is a list of one or more 64-bit integers.

Each of these listed integers are used to indicate settings that are allowed to be set by boot loaders, in a secure boot protected by Bitlocker or other security features of Windows used at boot time to load the OS image. These values are NOT documented at all, but apparently they seem to be using the same format as BCD element types (which are the only one documented).

You evidently should not validly assign the value 0x17000077 in the list of values given to AllowedInMemorySettings in BCD (it would mean recursively assigning a AllowedInMemorySettings within AllowedInMemorySettings itself).

But you can find the 0x15000075 assigned in the list of values given to AllowedInMemorySettings(=0x17000077). What this means is completely unknown, but apparently the Windows installer itself (or some Microsoft agent executed later, e.g. when installing and activating Hyper-V, Windows containers, MDAG, etc. or during a Microsoft support for specific machines, or to solve some known but unusual UEFI BIOS issues) will add one or more such "magic" values (e.g. to allows the UEFI firmware or some of its extensions for AMD or Intel processors or specific chipsets and bus controllers of the PC or motherboard manufacturer) to work correctly or to secure it by blocking some Windows API that could corrupt their security).

Apparently, finding such AllowedInMemorySettings entry in a BCD store is used to bypass some security checks or restrictions, by activating some conditional internal execution paths in the Windows OS boot. But the problem is that this could be used as well by malwares or spywares to avoid a detection.

One thing I have found on some PCs, is that the presence of such undocumented values in AllowedInMemorySettings allowed to bypass the TPM presence, even if a TPM device is present: this causes the TPM device to disappear and no longer being visible and used in Windows.

With the effect of completely disabling Bitlocker from using the TPM device, and the impossibility to activate it. And the additional damaging effect of blocking you to install newer versions of Windows (now Windows will claim that there's no TPM device and so your PC is no longer eligible to an automatic in-place upgrade).

So Microsoft should really document these values that are quite common in fact (there are multiple possible values), and expose the solutions need to secure them or when they can be removed.

Note that the presence of such option does not mean that Bitlocker is running or has been installed, but it would prevent Bitlocker from installing automatically (e.g. by administrative "forced" requests on a domain), when this is known that converting a non-encrypted volume to an encrypted one is NOT SECURE AT ALL: it can crash and make all your data unrecoverable on the volume, damaging the basic NTFS structure, notably when the encryption conversion is started and there's an additional admin option that gives a time limit of 10 minutes before a forced reboot! 10 minutes may not be sufficient, even when Windows is installed on a SSD, to allow the started conversion to be recoverable after the reboot).

Unfortunately admins of Windows domains (including admins at Microsoft itself) are stupid and make false assumptions. Forcing a reboot after 10 minutes should ABSOLUTELY NEVER be used by any admin. At most all it can do is to block Windows and wait, and if there's a bitlocker volume encryption started, it should be cancelled and reverted to allow a safe reboot. And forcing a volume encryption should only be done with the user present and controlling it (after making sure as well that we have enough battery or we are in a safe power condition, and also possibly delaying hat conversion to be started by the user only after making a safe reboot to terminate the installation of other things, notably after installing or upgrading some very critical system drivers like bus drivers).

I've seen Microsoft using such forced reboots, after starting a forced convertion of ALL accessible NTFS volumes to use Bitlocker (even volumes that were not mounted at all, or that were in remote systems like a NAS) and this was forcibly initiated on ALL volumes at the same time with absolutely NO chance of terminating the initialization on all these volumes in the allowed limit of 10 minutes before a forced reboot: the effect was dramatic: all these volumes became unrecoverable (I have lost hundreds of gigabytes, including ALL MY backups that were on external unmounted volumes, but that the abusive Microsoft admin found by enumerating buses and looking for all mountable volumes apparently containing some NTFS filesystems).

And even after trying the paid Microsoft support, no solution was found to recover my volumes (in fact it was impossible to undo the partial encryption of ALL NTFS filesystems that became permanently corrupted, apparently by multiple reencruption using a different set of encryption keys and without even providing any safe backup of these keys). I had then lost months of work (plus many years of personal backups that Windows should have NEVER touched).

The lesson from it: NEVER TRUST Microsoft AT ALL, or any Windows admin (especially when they DON'T OWN your hardware and your own data)! Don't use backups accessible from a bus or network by a simple mounting command by software. You must plug them specifically and securely only for the time to create backups physically unplug the backup volumes. But this means that backups on Windows cannot be safely automated, this requires a human presence and a human agreement (the human may need to perform some other safety checks before accepting).

But Microsoft always think that it knows everything better than us: BitLocker in Windows is a VERY DANGEROUS MALWARE for all your data, that are in risk of being stolen and permanently damaged without your consent. Bitlocker is as much dangerous as other Internet-propagated ransomwares that will in fact not recover your data even if you pay their ransom! I paid the ransom claimed by Microsoft for the support, and got nothing in response, even after waiting for months (all I could do is to cleanly reformat all my storage disks, I have lost all data definitely).

There are better non-Microsoft alternative tools if you want to encrypt your drives securely or perform backups/restorations (and they are respecting user choices, not stealing their decision without prior information and explicit consent). Don't use Bitlocker, and please Microsoft stop forcing users like you do when managing Windows "as a service", without providing any help, support, or documentation: these undocumented BCD settings for Bitlocker are such thing that should be FORBIDDEN by law and Microsoft should pay severe fines to its many customers that were abused.