Actually the first should be the latter, not in the sense that there shouldn’t be a list of switches, a list of options somewhere, or no terse sum-up docs for all those little things, but that those sum-up docs should be the header to a guide.

I may be getting old but I think earlier UNIX had that, and we kinda lost it: Back when programs had few switches the man page would have a header explaining the command tersely – “foo grobnitzes flobboxes” or such, two or three options described equally terse, then you’d get into usage and examples. Nowadays, where GNU less lists its options as

less [-[+]aABcCdeEfFgGiIJKLmMnNqQrRsSuUVwWX~]
            [-b space] [-h lines] [-j line] [-k keyfile]
            [-{oO} logfile] [-p pattern] [-P prompt] [-t tag]
            [-T tagsfile] [-x tab,...] [-y lines] [-[z] lines]
            [-# shift] [+[+]cmd] [--] [filename]...

, note the fucking alphabet in the beginning, it’s pages upon pages of terse technical definitions in the rest of the manpage. (Yeah I know less probably doesn’t need extensive usage docs it’s pretty self-evident but my point stands).

We have hypertext now. This can contain a gazillion links to this. And please no no gnuinfo I still don’t know how to navigate that thing, I barely know how to exit it. Lynx and w3m prove that it’s possible to do intuitive design with links in the terminal, do better. Me wanting to quickly look stuff up is not the right time to insist I learn your awkward pet documentation interface, Richard.

They are only second rate if not used.

Your wiki can be hosted in a VCS. gitit I think is the original and as it uses pandoc it’s probably what you want to use. (Not so) random example wiki powered by it.

Two big advantages over plain text in VCS: You get to look at hyperlinked and whatnot output, and non-programmers can contribute.