On the topic of root lazy-loading, I did observe the following behaviour when trying to load ISRG Root X2:
If the system already knows the cross-sign of ISRG Root X2 (signed by ISRG Root X1), it will use that for path building and will not load ISRG Root X2 self-signed into the trusted root store. This even applies when visting sites like valid-isrgrootx2.letsencrypt.org, which do not send the cross-sign themselves.
On such a system, in order to get the system to lazy load ISRG Root X2, you need to remove the cross-sign first. In order to do that, I had to open certmgr as administrator (I did this by opening it from an elevated command prompt), then looking at Intermediates and either deleting ISRG Root X2-signed-by-ISRG Root X1, or by moving it to untrusted. Note that certmgr shows different certificates depending on if you call it elevated or not and it can also differ between user accounts.
Then simply visting valid-isrgrootx2.letsencrypt.org from a client that uses the Windows platform verifier caused Windows to lazy load the self-signed version of ISRG Root X2 immediatly.
Note that compatibility-wise it makes no difference whether the system builds a path up to ISRG Root X1 or ISRG Root X2 - they're both trusted and their EKU's are the same. Their only difference is the expiry date, and I hope that Windows will lazy-load a "better" version of ISRG Root X2, once the cross-sign expires (in about 4 years).
This is just interesting to know in case you wonder why your system might not load ISRG Root X2 - Windows can be very lazy.