I moved all the WSGI stuff out of my AJP C library project into its own project: ajp-wsgi. I polished it up a bit, gave it a command-line interface, wrote a better build system, and even wrote a simple README for it. You can find it here.
Note that this is not a Python extension. Rather, it is a 100% C WSGI implementation... that executes the application in an embedded Python interpreter.
It's moved beyond a proof-of-concept and is quickly becoming more and more practical. (At this moment, my personal wiki is running atop it. Maybe I'll switch my Trac sites and shorten over to it as well.) But make no mistake, it is very much alpha-quality and untested.
Decouple the WSGI code from AJP, opening it up to an SCGI implementation. I have no interest in making a FastCGI version, so don't ask.
If not thread pooling, then maybe a thread limit at least?
Multi-app support. Maybe read configuration from an INI-style file (each section header would define the module:object for the app).
Figure out/understand the oddity with mod_proxy_ajp. It seems to stream the request body whether solicited or not. It also sends an unsolicited EOF packet. If this is the case, then mod_jk seems like a saner implementation... but maybe this is the future direction of the protocol?