The project is cool, I enjoyed the walkthrough, and I like Clojure and love seeing discussions applying it in everyday use.
But this particular design decision, which works well for the author, is worth flagging for others as it bumps against a variety of first principles in Unix and Lisp such as simplicity, composability, and interop/portability apart from tools.
For example, from your comment:
> Instead of … filenames … have an index [of] filenames to read + the metadata
And now you have to sync an index of metadata on top of the existing index and files. If you interact with the files through any other tool, you can have files not in the index, or index w/o files…
Plenty use cases depend on that. Here’s a user asking about inability to independently edit files with Joplin:
https://discourse.joplinapp.org/t/yaml-front-matter-metadata...
But here we already have an index, the directory tree, that already contains the critical metadata: name, created/modified dates, sufficient to retrieve the media and the media specific metadata. Can even natively leverage tags if we use file tag metadata natively supported in some filesystems, then the OS GUI and other apps can search and retrieve w/o extra moving parts, and still read custom metadata from the media (in this case plaintext markdown article) itself.
Also, most “bog standard” markdown editors have, by now, a toggle to pretty print or table-ize frontmatter, and suppress it on publish (especially since many leverage pandoc which supports that). When they don’t, it’s just three dashes and some TOML, works fine as text.
Put another way, YAML Front Matter is to plaintext .MD articles as ID3 tags are to MP3, AIFF, AIF, M4A, M4R, FLAC, OGG, WAV, APE, ASF, and WMA audio files.
TL;DR:
Even if you maintain a separate index, you still want to write back the metadata into the media file standard so the media outlasts the media management tool.