I think there's some confusion about what WSGIKit is, and what I intend for it to provide:

• WSGIKit isn't WSGI. "WSGIKit" is, rather, a poor name for a project. It really needs a new name. Greg McClure suggested Underware, which kind of amuses me, but probably is a bad choice.
• WSGIKit isn't a WSGI server. Still, it does include glue for servers (just a couple now, but more in the future). It will probably be distributed with some servers, just because that's more expedient and gives people a better experience.
• WSGIKit includes several pieces of middleware, like an error catcher and a session manager.
• WSGIKit includes a from-scratch reimplementation of the Webware API, but that API is completely separated in a subpackage (wsgikit.webkit) and while it has (so far) driven the specific features, it isn't preferred in any way.
• I use Zope Page Templates in the tutorial, but that's even less connected, just some code to integrate ZPT written for the old Webware, that also works for WSGIKit Webware.
• I've included a script (app-setup) for setting up new application instances. This creates files and directories, and can provide custom commands as well. This uses "application template", the first of which (webkit_zpt) is based on Webware, Component, and ZPTKit.
• It includes a script for starting up servers and the general WSGIKit environment. This involves creating a stack of WSGI middleware, some application loader, and loading the appropriate configuration.
• It includes configuration. Configuration currently is just done with Python files. To a degree other formats could be supported, though often that is more difficult in practice than theory. This configuration is used by a variety of middleware as well as the server. It is also used by app-setup and possibly other components. I've already integrated SQLObject (through sqlobject-admin) into this configuration.
• It includes a single URL parser at this point, that matches the general algorithm of Webware URL parsing. This is also, essentially, the application builder -- it loads modules and files, looks for appropriate objects in those modules, and can do small amounts of conversion to get them in an appropriate state. It doesn't strictly "know" about Webware, but not-so-coincidentally it works with the Webware model. I'd like to include other URL parsers/application builders -- as few as possible, but as many as necessary to support the full range of URL parsing we see in the wild. The full range isn't actually that full -- the current parser plus an object publisher or two (configurable to provide backward-compatible parsing) should do.
• The basic architecture is similar -- I think -- to Java servlet filters. Or CherryPy filters. Or other pipeline-like systems. Still when possible code should be provided as libraries instead of middleware (it's more predictable, easier to use), but that's not always possible. By using generic middleware -- especially as we add more configuration to the middleware -- we can introduce global and interesting functionality to an application or a set of applications.
• It includes a kind-of test framework, based on py.test. Kind of a framework, because it's not very complicated, but I've found it quite convenient -- WSGI makes it easy to test individual pieces in isolation, and to create fake requests. So unit testing can occur reliably on a fairly granular level. I've also been building a bit of a framework for testing tutorials with doctest.
• Hopefully soon it will provide a nice installation experience, including a large download that includes all sorts of optional pieces that might be useful or helpful.

So... that's what WSGIKit is. I'd really like to support more frameworks, more servers, and bring more developers in. There's room! I'm willing to give commit access to anyone who's been around in the community, or really anyone who shows a little interest and competence (and of course plays well with others) -- the nice thing about version control is that nothing is permanent, so we might as well take advantage of that. I think WSGIKit has the potential to provide a compelling and simple installation and configuration experience for a whole variety of frameworks, removing the diversity that's not interesting but just annoying. At the same time it shouldn't infringe on any of the interesting diversity. It's also a good, testable, decoupled architecture to make a solid foundation.