It does not matter much when the fix is arriving. As long as it is unfixed, future LCUs will not be able to install DBX revocations (or add more certs to DB, but that will likely not happen before 2037). But as soon as it is remediated, the next installed LCU will again detect that the DBX is out of date and apply it again. You can also manually trigger DBX update by setting AvailableUpdates to 0x0002 once you know that the issue is fixed and DBX updates are missing.

This question has also been asked in last month's AMA, and the answer pointed to https://github.com/microsoft/secureboot_objects/issues/369 where Doug Flick from Microsoft clarified that Microsoft officially supports the scenario when firmware vendors of (virtual or real) machines deploy the Microsoft OEM Devices PK instead of their own PK, and that such devices will get serviced (with Secure Boot certificate updates) like Microsoft's own machines. There are also some details about the security of that PK in this thread, mostly for as information for vendors whether using this PK will be more secure or not than their own PK (which would require their own certificate infrastructure). Microsoft also has performed Secure Boot PK updates on devices where the PK private key leaked, to replace the leaked PK by their own OEM Devices PK.

So I'd say, from a Microsoft standpoint, manually importing that PK is fully supported, on any machines where the firmware vendor suggests so (be it real or virtual ones).