Wifi has an "interference robustness" option which is designed with microwave ovens in mind. The power output of a microwave is a sine wave, because it's powered from your AC line power, and doesn't emit energy during the zero crossings. "Interference robustness" times packet sends (and lengths) to be when the microwave is producing the least amount of power. Thus, you spend half of every 60th of a second irradiating your food, and the other half downloading videos. (Needless to say, having this on and your microwave going in the background reduces throughput. But, dropped packets are worse than small packets that always get through, and this aims to eliminate completely stomped-on packets.)

Wifi also has a listen-before-talk model. If it "hears" a microwave running, it thinks it's another station transmitting, and backs off. This feature of the protocol is why long-range networks worked so poorly in the past. If station A can't hear station B, but the AP can hear both of them, then A and B are going to step on each other and the AP won't be able to communicate with either station. This is why the "enterprise" way of deploying networks was to have a ton of access points running at low power; that works well with the listen-before-talk model since the AP likely can't talk to or hear stations that are too far away for the stations in its range to hear.

I don't know if interference robustness still exists in modern standards, as I haven't seen it in a control panel for decades, but it was definitely in 802.11b. I have never tested Bluetooth (or read the standard), but basically... the industry knows this is a problem, and handled it a long time ago. Bluetooth might ignore the problem because it plans on frequency-hopping (away from the microwave) anyway, but like all software, that can easily be bugged.