Couldn't you just make a (deep) copy of the previous object, and use that as the next object, allowing users to overwrite any fields that changed? This way, the fields would be what the user last entered, individualized per user, and updated as they chnaged those fields.
If you have a way of remembering the last thing entered per user, you cold even preserve this between sessions.
The OP comments:
Unfortunately, making a deep copy of an object messes up the objectcontext when relationships are involved. A new object with relationships either needs to have new relational objects created or existing objects queried from the database.
So? If the relation is to an another entity (a foreign key in the database), it's a uses-a relationship, and you just retain it. If it's an attribute, you copy it.
For example, lets say your form is data entry about employees, and ithas a drop down for, I dunno, employeeType, that's either "Exempt" (no overtime) or "Non-exempt" (gets overtime). You pulled the values for employeeType from the database, and you want the next employee entered to have the same values as the last entered employee, to save the data entry people keystrokes. So your deep copy would just associate the copied employee with the same database employeeType.
But for attribute data (like name), you'd make a copy.