Essentially the writing process for a serial usb type will cause the temporary build files under user/AppData/temp/ to get corrupted and all files inside of the temp folders need to be deleted before a successful serial usb type write of the program can be made and the serial port will come back up.
I don't know what you mean by "the writing process".
Maybe if you understood the process a little better and where to find info, you could describe what's happening more clearly? I'll try to give you a little background info...
What commands Arduino runs is controlled by platform.txt and boards.txt. You'll see Teensy uses a program called "teensy_post_compile". This is the last step done after Arduino has written all the files to the temp folder. It's not open source, but you can find the program in hardware/tools and run it yourself if you want to experiment. It requires command line args for the file and directory where Arduino put the .hex file, and also the tools folder ({arduino}/hardware/tools). In that tools folder you'll also find "teensy" which is the Teensy Loader program, and "teensy_reboot".
The teensy_post_compile utility's main function is to launch Teensy Loader if it's not already running, and then communicate the filename and directory. It also puts Teensy Loader into auto mode. If you click Help > Verbose Info in Teensy Loader, you will see much more detail about what's happening. When it gets communication from teensy_post_compile, the commands are logged in that verbose info window.
As a last step, if you gave the -reboot option to teensy_post_compile, it will run teensy_reboot. Earlier versions of Arduino just ran both of these, but in the latest versions the process isn't so flexible to run more than 1 program, so teensy_post_compile takes care of running teensy_reboot.
This teensy_reboot utility is the part which actually tries to find any connected Teensy and send it the request to reboot.
Both of these programs log info about what they're actually doing to teensy_reboot_log.txt. Together with the Verbose Info inside Teensy Loader, you can get a pretty detailed picture of what they're really doing.
Once teensy_reboot finds a Teensy and manages to send it a request, it's done. That's all it does.
When Teensy reboots into bootloader mode, the upload happens because Teensy Loader was put into Auto mode. Teensy Loader always reads the HEX file right before actually uploading. It also looks at the .ELF file, if present, to check which Teensy you've used.
None of these programs should ever write to the HEX file or anything else Arduino created. Teensy Loader only reads it. The teensy_post_compile and teensy_reboot programs don't read or write the files Arduino created. They only writing they ever do is to teensy_reboot_log.txt.
Perhaps a good question is whether the files were originally created correctly by Arduino and were later messed up somehow, or if they were bad from the moment Arduino wrote them? You can use "show verbose info while compiling" from File > Preferences to get Arduino to print the actual compiler commands it used. Maybe if you try running the (huge) final linker command to create the .ELF file, and then the objcopy command to convert it to .HEX, you could see if they recreate good copies of the data?
I would very much like to know why this is going to wrong on your Windows machine. Hopefully this info can help you investigate and share anything you learn? I can tell you this absolutely does not happen when I run here on Windows 10. Something is really messed up....