Yes, in fact you'll find lots of source code out there that will write test.txt.tmp and then close and rename it to test.txt, exactly because this is an issue in all filesystems. From the sounds of it the time window during which RPi is vulnerable is longer than usual. A careful choice of filesystem journaling/integrity flags would probably help.

The fact that there's a 0-byte file instead of a completely broken file system is already the result of a journal. You can reliably observe this with ext4.

It was an unsafe shutdown, meaning I just pulled the plug. But it was at least several seconds after saving it. I've never seen behaviour like this before.

Most sd cards are formatted fat32, and do not have a virtual filesystem cache and write scheduler buffering work in ram for them.

Also raspis do NOT like big fast SD cards with tight tolerances. I've had the best luck with old class 4 cards. Class 10 cards don't last nearly as long with regular power cycling.

You can force a partition to be mounted "synchronously", where writes aren't buffered in RAM and then flushed later -- every write blocks until it is written to disk.

The options are the third column in your /etc/fstab file. For example, if you had "errors=remount-ro", you'd change it to "errors=remount-ro,sync".

(Or is the Raspi problem actually in hardware?)

Did you ever run linux with ext2 (not ext3 or ext4) on a desktop computer in the early days? It used to fail spectacularly on unclean shutdowns. IIRC linux used to delay/buffer writes up to a minute or so. (Maybe it still does?)