Sorry for not bringing this thread to your and Dave's attention earlier, I assumed that somebody (like maybe the OP) had already done so 
No, I was aware of it but I was under the impression it was resolved. It was far worse at one stage.
I'm not familiar with SMF internals and these plugins, but if you ask me, I would say that the location to write the attachment on disk gets written somewhere into the database, associated with the current user.
The database just stores meta data and SMF writes each file to the disk with a name it generates, which is the unique primary key of the table combined with a hash of it's filename, the current time, and a random number.
$hash = sha1(md5($filename . time()) . mt_rand());
$filename = $id . '_' . $hash;
Subsequently, a stupid race condition causes the file writing job to use the previous post's filename before the cached value is updated. Or maybe it doesn't get updated at all for some other stupid reason.
Yeah, I am still not sure as to the cause as this should be impossible. PHP isn't multi-threaded per request per request, and since the filename/hash used is guaranteed by the database and the filename generation method that SMF uses to be unique, it should never happen.
What is even stranger is the post times of this latest incident was about 1/2 an hour apart, which rules out a race also. And finally, the new file that is written to disk incorrectly, is different from the file that it should be if it were just overwritten, it has also been altered/processed (this confirms it's a PHP/code bug, not fs or database)
Also what is further strange, SMF generates thumbnails when you try to view the thumbnail on the fly, it doesn't do it at image upload time. For this to have worked, the file on disk's contents needed to be correct to begin with.
I am on break for a few days, but as I can I will try to debug this futher.