The patch I proposed works by adding a field to the 'data_records' table (to indicate that this record replaces/is replaced by another record) and then duplicating the 'data_content' entries for that record (filling them with the new data). On approval, the contents of the new 'data_content' entries are copied back over the originals and the new 'data_records' entry is discarded.
Based on your suggestion an alternative implementation would be to add 5 extra fields to the 'data_content' - 'content_new', 'content1_new', 'content2_new', 'content3_new', 'content4_new'. The 'new' entry could be stored in these, with the choice of showing the new/old version being based on the ownership / capabilities of the viewer.
This would get around the untidiness of creating a temporary record for unapproved entries, but does bloat the 'data_content' table a bit.
Obviously, at the moment only 'content' and 'content1' appear to be used (content1 appears to be used as a FORMAT_* field for 'textarea' entries), but this proposal will retain the flexibility for future use of the other fields, by other 'data_fields' types.
I hope that make sense (it gets very confusing talking about records and 'data_records' entries, about fields and 'data_fields' entries).