The issue isn’t multithreading. Of course they know that. It’s that they want the UI to show all menu items when you click it (otherwise you’ll say “sometimes PDF Reader is available and sometimes it’s not!!”

Windows doesn’t have performance requirements for most plugins/extensions. It would be great if they did, but it hasn’t been the culture of their ecosystem thus far.

Oh they know about multithreading. The problem is Microsoft's commitment to backward compatibility -- the Explorer COM interfaces that third-parties can build shell extensions on are all old enough to be from an era when 99% of users never used Explorer to browse anything on a network so their being synchronous didn't matter, and also from an era when asynchronicity wasn't common and was poorly supported by compilers and when PCs had low enough specs that it didn't make sense to spend the resources to provide asynchronous shell APIs.

And because Explorer continues to support those interfaces today, that means if anything integrates with the shell via those interfaces, Explorer ends up with lots of operations that are forced into being synchronous. You can avoid some of it by being extremely selective about what sorts of shell extensions you let be installed.

You can add as much multi threading as you want, but if you need to wait until all threads are done, the entire window will stall to show you that context menu you requested.