I d'like to point out that this message is posted even with a template app that contains nothing else than a text field in the window's content view.

Of note, objects that turn into faults are those that has no pending changes, that is, those that were not inserted nor removed in/from the ordered collection. I can avoid the issue by making dummy changes to these objects, such that they don't turn into faults during the next save, but I'd like to understand the root cause. Maybe I don't know how to manage ordered collections properly. To insert an object, I use insertObject:inSubfoldersAtIndex and I don't modify other objects of the collection. Should I reorder all objects? The documentation says little about ordered to-many relationships.

I see these messages in red in the Xcode console every time I click in a text field, even for a template app that only has one textfield. This is extremely annoying.

Update: the to-many ordered relationship doesn't have to point to the same entity for this issue to occur (in my example, the "parent" and "subfolders" can be different entities).

Hi Chen. I too wonder why the binding does not bring back the object's attributes. Here a link to a simple project. https://upoitiers86-my.sharepoint.com/:u:/g/personal/jean_peccoud_univ-poitiers_fr/Eap9s3nnTfZGod0dfcDzhZ4BS6KVlJ-XCChuzsEhQyjpwA?e=YmSvqb To reproduce the issue, just click the "Swap folders" buttons, which reorders two Folder objects in an ordered to-many relationships, then saves the context (see swapFolderPositions: in AppDelegate.m). The name attributes of the folders are bound to two text fields, and you will see a name disappear when a folder is turned into a fault (a message is logged in the console when that happens, since I override willTurnIntoFault.

I meant Sequoia, not Sonoma.

It seems I didn't have a choice, so I renamed the class. I used @compatibility_alias, but I still needed to update the encoding and decoding of objects to maintain backward and forward compatibility . I guess I should have added prefixes to class names in the first place, but Apple may consider using more specific names for its (private) classes as well. "Trace" is very generic.

Nevermind, I just realized I used the offStateImage rather than the image property for these menu items. The custom images indeed replace the default images, as expected.