Kiki (Karig's Wiki) will be a Wiki more in line with what I want in a Wiki:

Better design.
Better authentication. Editor is in its own folder, which can be password-protected.
Tags instead of folders. Every article has its own name unique among all articles, like Wikipedia. Instead of folders, you attach custom tags (either keywords, or fields with values) to articles.
Graceful degradation. The view and edit pages should POST their data to the server and have PHP scripts do all the work -- unless JavaScript and Ajax are present. The JavaScript verifies that Ajax works; if so, it changes the page to POST using Ajax (and to download only the data needed, instead of a complete updated view or edit page). (See also: Unobtrusive JavaScript.)
Ajax. Using Ajax to change the contents of the current page -- to bring data to you instead of making you go surf for it -- can make a Web application feel much less cumbersome.
Autosave. Kiki will use Ajax to save changes to a draft file on the server, so if you leave the page without saving changes, Kiki can restore the changes to the editor when you return. Changes are not saved to the public file until you click the "Publish" button.
Searches. You can search for all articles using tags, text, or both. You can display the results as links or as the actual articles (multiple articles can be displayed on one page). You can have the results sorted by name or by tag. You can even save searches, give them a name, and then surf to them as if they were articles, and the searches will be rerun.
Flat-file storage. Storing articles in plain text files rather than in databases has some advantages: Text files can be examined in any text editor. They are easy to download (for backup purposes). They are simple to search, and if you store multiple articles in a single text file, then searching a text file can be very fast. And while a Wiki package might require you to use a tool to set up a database for the Wiki's use, text files are dead simple to create and rearrange.
Support for literate programming. To support literate programming, and to allow me to store Kiki's code in Kiki itself, I'll want a utility (in a password-protected folder) to search for articles with tags "type=code" and "language=PHP" and "project=Kiki" and to export the code sections of the articles into PHP scripts in a specific folder on the server.
Line numbers for code sections. Kiki will use jQuery to hunt for code sections and to insert a line number before each line. (Fallback position: Add line counts before or after each code section.)
Sorting displayed articles on the fly.

Uses for Kiki:

Literate programming via CSS. Literate programming is a style of programming intended to make programs as readable as possible to human beings. CSS (and jQuery) can be used to hide all parts of a Web page except the code sections, which can be copied into a file, saved as a PHP or JavaScript script, and run.
Conlanging. Each word definition goes into its own article. Words can be compared directly by displaying multiple articles on the page at once.

Design considerations:

Simplicity. I want to keep the code as small and simple as possible.
Flexibility. There should be as much flexibility in the display of articles as possible.
Speed. (flat files, ajax)
Customizability. Some parts of Kiki are stored as articles, so that you can edit them in Kiki's editor. These will have special tags.
Borrowing code. Some of the functionality of Kiki already exists. Kiki will use Textile for markup, jQuery for Ajax calls and DOM manipulation, and JSON as the data format.

Kiki on Kiki

I want to maintain the parts of Kiki as Kiki articles. The actual code will be stored in <pre><code> sections within articles, and I will have a tool to extract these sections and create actual working PHP/HTML/JavaScript files from them. The articles themselves serve as an explanation of the various parts of the Kiki code -- not only how it works, but why I wrote the code I did and what problems I wanted to solve.