This was definitely a thing. You can recall an artifact of folk proof in this detail, by recalling a lot of more technical users and professional IT/desktop support staff in computer labs using C: as a system drive, and D: as the work area containing user files, even if it was a single user machine. Losing the C: partition was a bad burn, bad enough that you didn't let it happen twice.
Years later, even in the Vista days, I had a partition destroying error from a truly innocuous action (like renaming some file; and that NOT being just a coincidence, but a repeatable error with Google results), and had a flabbergasted flashback to a prior C: drive implosion, that reminded me why you always divide the bootable system install off to its own untouched C: partition, and always only put the things you care about on the D: drive, and create lots of backups.
This was real. Never touch C: and don't trust it. Never put anything that matters in the C: partition.
On windows, code pages were not sent to the swap file, because that data already had a copy of that data in the program's original .exe file! Instead of writing the memory page to the swap file, simply freeing the memory was much faster and saved a lot of space on the disk reserved for the swap file. The code pages were supposed to be read-only, but some kind of bug(s) would cause the memory pages to be seen as normal memory, where writes would mark the page as "dirty" and eventually the VM would write those changes to the swap file. Unfortunately, for code pages, the "swap file" was the original .exe, so the changes to the memory page would corrupt the .exe, probably requiring it to be reinstalled.
> always divide the bootable system install off to its own untouched C: partition
They might have been using 'ghost' to restore the C: partition over the LAN at boot time. This was very common in professionally-managed settings.
Do you mean Windows modified user programs without warning? It seems like it was a serious bug.
And yes, it was a serious bug, that might have been responsible for why Windows seemed to have a "half life". Over a given period of time, each system had a chance of corrupting itself. Some systems would be fine for years, but many needed to be reinstalled after a ~year.
None of this is to say that MS-DOS and Win3.x isn't a bizarre maze of assembly-language hacks. It was unreliable as hell, though the entire PC software ecosystem and playing fast-and-loose with tricks like directly accessing hardware was as much to blame as anything.