> Right now if you select() with a subset of fields and then flush() it is possible you could screw up the documents data.

The UnitOfWork refresh hint sets only the projected data as the original document data (for changeset calculation), so I don't believe we would end up `$unset`-ing other fields, although we could certainly add new fields, which could get messy with the "add" collection strategies. I agree that an immutable object would help here.

> I'm more for partial object type than immutable one

A partial object type introduces a lot of complexity. I do think that's what the current code is attempting to do with this refresh hint and overriding the original data for the changeset; however, once we get into the realm of collections (where changes aren't simply set/unset operations) or increment strategies (where a field change should result in `$inc`), it gets very messy.

> what if dev has full and partial document and changes some fields in both of them? Should they be connected somehow?

This is actually what the `merge()` method on UnitOfWork is intended for. The user needs to decide how to combine their document objects (i.e. separate instances of the same class), but you ultimately need to redeem a document with UnitOfWork to receive back a managed instance. The return value of `merge()` may or may not be the same as what you passed in, which is why the documentation insists that users stop using the argument and rely on the return value going forward.