I didn't do a thorough investigation, so instead of a typical bug report I'll just give my anecdote.
So I'm not really sure what the "bug" is here, since this behavior actually makes sense. The part that I guess is buggy is that the item's (driver's license) information isn't dynamically updated in the 1P mini instance when in edit mode. It's like 1P mini makes a local temporary copy of the item for the duration of the editing session, so that it didn't know the same item was edited in the main window. Then, upon ending the edit session (which I did by first dismissing and calling 1P mini, which I assume would bring it back to its default state), it compares the item's information with that in the database, which had by now been edited using the main 1P window, and sees the discrepancy.
I guess my suggestion would be that edits made in another instance (in this case, in the main window), while an edit session is ongoing should be immediately copied over in the event that the same item is open in another edit session elsewhere (e.g. the 1P mini window). A crazy use case would be that I have the same item open for edits in the main window and in several 1P mini windows, and I edit each field of the item using a different window: How should that be reconciled? The only consistent solution would be that the edits in one window are immediately reflected in the others, that way the crazy user who likes to edit things simultaneously in multiple windows gets what he expects.
1Password Version: 7.0.5.BETA-1 (70005001)
Extension Version: Not Provided
OS Version: Not Provided
Sync Type: Not Provided
Referrer: forum-search:mini save conflict