The symptom described (full size due to metas) can be caused by a de-serialize failure. I've done that a couple times by manually corrupting postmeta values in phpMyAdmin. I bet there is a lower-level cause and solution than this the_content thing, and it has potential security implications.

Post meta values are stored as UTF-8 serialized strings. This means they are not binary-safe, and therefore any image headers not stored as UTF-8 or ASCII will be broken without conversion. nacin has added an unconditional utf8_encode conversion to any header fields that did not previously have it. This prevents serialization from blowing up at the MySQL layer.

The utf8_encode() function is not appropriate for any image headers not stored as ISO-8859-1 or ASCII. This means all UTF-8 and UCS2 image headers are broken by WordPress. The current obstacle in fixing this is that we do not have any UTF-8 or UCS2 encoded sample images with which we could test a patch for this ticket.

Something else that needs testing is what happens when a filename contains non-ascii characters? I assume they are converted to the website encoding before transmission, but between the flash uploader, serialization, and UTF-8 DB columns, I have no idea.

Going to mark this one as fixed, unless my memory isn't serving me well I think we did all we could here. There is also #9417 with similar issues that can be handled in 3.1. Please open a new ticket if there's something else going on here.