There is a section about that in the Secure Boot Troubleshooting document:

https://support.microsoft.com/en-us/topic/secure-boot-troubleshooting-guide-5d1bf6b4-7972-455a-a421-0184f1e1ed7d#ID0ELBP-button

For Scenario 1 (bug in firmware implementation), you cannot reliably detect it. If you have identified affected firmware vendors/versions, you can mitigate it by disabling or suspending Bitlocker before applying the Secure Boot updates, restart another time when they have been successfully applied, and re-enable Bitlocker. (Note that Microsoft does not endorse increasing your attack surface by disabling or suspending Bitlocker, you will have to do your own risk assessment on that).

For Scenario 2 (There is a PXE server early in the boot sequence which will most of the time do nothing more than trigger BOOTNEXT, and uses a bootloader signed by the 2011 certificates), you can mitigate it by moving Windows Boot Manager to spot 1 in your boot sequence or temporarily blacklist the MAC addresses of your devices from the PXE server's DHCP configuration so that PXE boot is not attempted or uses a bootloader signed by the 2023 certificate.

But in general, there is no reliable way to predict whether Measure Boot TPM resealing is working on your current firmware or not, otherwise Microsoft would probably add a safeguard lock for that :-)