"Take the library experience. Reject the storage model that produced it. They were never the same thing."
What Bear Gets Right
Bear is genuinely admired here, and for good reasons: a calm sidebar, instant search, and no folder friction — you write, and finding things later just works. That library experience is exactly what Rekindle wants once it grows past single-file mode. So the honest question is: how much of Bear should be copied?
What Bear's Storage Would Cost
The part that must not be copied is the storage model. Bear keeps notes in its own database as the master. Import that into Rekindle and the vault forks: the DB says one thing, the .md files say another, and now you own reconciliation between two masters forever. That's the exact reconcile-hell the whole stack refuses — the same reason cwkPippa has one ground truth and rebuildable mirrors rather than two authorities kept in sync.
Bear's model DB is master, files are an export -> two masters to reconcile
Rekindle's model files are master, index is derived -> one master, rebuildable view
# The library UX is compatible with BOTH. Only one of them
# forks your vault and hands you a reconciliation problem.Take the Experience, Not the Storage Model
The key realization is that the library experience and the own-DB storage model are separable. A sidebar, instant search, and no folder friction are all views — they can be computed from a derived index over plain files just as well as from a master database. That's the Obsidian sweet spot: Bear's calm library feel, on file-canonical storage, on the same CM6 engine Rekindle already stands on. So Rekindle takes the experience and leaves the storage behind.
This is a general move worth naming: when you admire an app, separate the experience you want from the architecture that happened to produce it. They're usually not the same thing, and copying the architecture to get the experience is how you inherit problems you never wanted.