Unplugged it and put it in my PC, came up as a RAW unformatted drive. Formatted it as FAT32 and back in the printer and all is working again.   Only question is how this could have happened.

If you are using the "power loss recovery" feature, the printer will write the current state of the print job to the USB drive. This happens after every line of gcode, I believe, otherwise it would not be very useful for recovery. Just do a line count on a gcode file and you will see how many write cycles there are for just one file. For instance the gcode for the Prusa Belt Tension Meter is half a megabyte and already has over 20k lines. This is probably also the cause for the drive getting very hot, which was reported by many users. USB thumb drives were no created for the purpose of being written to continuously and they will fail if treated this way. That is why it is not recommended to use them as e.g. a boot drive for an operating system.

Ah, that would be an explanation for USB drives failing prematurely. I was not aware that this is how the "power loss recovery" works. I was assuming a separate buffered memory exists to remember the current state, or a "poor man's uninterrupted power supply", e.g. a gold cap which gives the CPU a few seconds to write the state to USB if (and only if) it detects a power outage.

I assume the recovery feature is enabled by default? I will disable it on my printer then, since power losses are very rare here. It would be interesting to know whether users who have encountered USB stick failure had "power loss recovery" enabled.

I wish Prusa would just get rid of the RESET button and revise the firmware to allow controlled recovery from errors vs uncontrolled RESETs.  In other words, when there is a problem such as a filament loading error, there should be more than just an option to retry.  There should be options to retry OR abort, which would methodically close the files as it recovers.

If this is the case, then leave all existing prints and just keep adding to the drive until it gets full, only then delete everything and start the process again, this way you use all the flash memory. I highly doubt that wear levelling is implemented in these usb drives.

I struggle to imagine that any USB stick -- even a very cheap one -- could be worn out in a matter of months via read cycles only. On the other hand, even a sloppy implementation of a FAT32 library should not be able to create any data inconsistencies as long as it only reads from the file system. Nevertheless, USB stick failures seem to be somewhat common with Prusa printers. Any ideas what might be going on there? 

I'm using PrusaLink for uploading print files to the printer, so the drive will remain plugged into the printer.

https://rufus.ie/en/