Displaying fixed and editable items in a Source List

I'm working on an app that has this exact same behavior, and here's how I'm doing it:

I have 5 main entities in my Core Data Model:

1. AbstractItem - an abstract Entity that has the attributes common to all items, like name, weight, and editable. Also has two relationships: parent (to-one relationship to AbstractItem) and children (to-many relationship to AbstractItem, and the inverse of parent).
2. Group - concrete child Entity of AbstractItem.
3. Folder - concrete child Entity of AbstractItem. Adds a many-to-many relationship to the basic Item entity.
4. SmartFolder - concrete child Entity of Folder. Adds a binary attribute predicateData. Overrides Folder's "items" relationship accessor to return the results of executing a fetch request with the predicate defined by the predicateData attribute.
5. DefaultFolder - concrete child Entity of SmartFolder. Adds a string attribute identifier.

For the "Library" section items, I insert DefaultFolder objects and give them a unique identifier so I can retrieve them easily and differentiate between them. I also give them an NSPredicate that corresponds to what Items they're supposed to show. For example, the "Music" DefaultFolder would have a predicate to retrieve all Music items, the "Podcasts" DefaultFolder would have a predicate to retrieve all Podcast items, etc.

The root-level items ("Library", "Shared", "Store", "Genius", etc) are all Group items with a nil parent. The groups and Folders that cannot be edited have their editable attribute set to NO.

As for actually getting this stuff in your outlineView, you'll have to implement the NSOutlineViewDataSource and NSOutlineViewDelegate protocols yourself. There's just too much behavioral complexity here to pump it out through an NSTreeController. However, in my app, I got all of the behavior in (even drag-and-drop) in under 200 lines of code (so it's not that bad).

Don't inject nonsense into your data set simply to support a view. This not only goes against the MVC design pattern, but adds needless complexity (ie "more potential for bugs") to the single most important part: management of user data.

That said, using Bindings with this particular scenario is what's causing so much friction. Why not eschew Bindings entirely? You're on the right track, I think, using the NSOutlineViewDataSource protocol, but you didn't take it far enough. Instead, rely fully on this (still perfectly valid and in some ways superior) protocol.

You'd essentially trade ease-of-setup (and ease of change notification) for full control over the tree structure.