This is it.

I would barely consider random snips about a thing/keyword, scattered over time, to be documentation.

Certainly, a problem was likely solved with this FYI system... but it wasn't a documentation problem.

Discoverability is often a major documentation shortcoming. They solved task-oriented discovery of 'how' snippets. Someone can search based on what they want to do, and not based on a specific command.

I also prefer the 'documentation is code' approach, but it doesn't solve the same problem.

I've been fascinated recently with out-of-line documentation, I was inspired by this project: https://github.com/adobe/hyde

A more robust implementation would parse the code to object-code, then emit a document(s) for the developer to fill in.

The killer feature of such a system is that non-code changes (whitespace, etc.) would not trigger a need to re-document, but seemingly benign changes that affect distant parts of code (or a -O4 being added to the Makefile) would trigger a round of documentation

That's a nice idea but hard to make work, unless you know of some way to write automated tests and do regressions against docs.

well, automatically ensuring the documentation is correct is hard/impossible, yes, but it's simple to check if code change X impacts Y usage, and Y usage is documented, yet code change X has no accompanying documentation changes, so code change X is 'incomplete' due to lack of accompanying documentation..

see also: BSD-derived os's commit history, etc.