I didn't design nstcl with any intent to replace AOLserver (now or in the future). I wrote nstcl because I like to use the AOLserver/(O)ACS-idioms in the work I do (both professionaly and just for fun) in Tcl/Tk (but outside of AOLserver). It's allowed me to be much more productive in areas outside of web development. Even when a script doesn't do anything database related, just being able to use ad_proc in tclsh is a big win.
The first version of nstcl came about because I found the pgtclsh database extensions interface to be so much more painful than the AOLserver database api's that I'd come to know & love over the previous three years, so I created wrapper procs to emulate the AOLserver API. From there it grew to support Solid, and then Oracle, plus other things like ns_sendmail, ns_hrefs, etc.
With the latest release came templating, a general code cleanup, actual documentation (I was getting sick of Kriston redesigning the AOLserver.com site and breaking all the existing link/URLs every couple of months), a test suite, and more supported database extensions.
I don't have any experience using a threaded version of tclsh, so I can't even begin to comment on the thread safety of nstcl. In general I think it should be no more and no less than any other library of pure-Tcl code. Another question would be the underlying thread-safety of the database extensions themselves, I suppose. IIRC Oratcl 4.0 claims to be thread-safe now, whereas previous versions weren't. I have no idea about pgtclsh and the others.
John emailed me and asked if I saw any obvious reasons that would completely rule out it's use with FastCGI. I don't see any issues that are insurmountable.
Obviously nstcl would need all the AOLserver API's related to HTTP & HTTPS requests/connection handling. My working version of nstcl 1.1 adds some additional non-connection oriented commands: the ns_schedule_proc and ns_config/ns_param set of commands, for instance.
I hope that anyone who decides to persue this path would _fully realize_ the speed difference between a C implementation (AOLserver) and anything written in pure Tcl (nstcl). That said, however, for low-end/low-volume sites, I imagine speed wouldn't be an issue.
BTW, there's at least one area where nstcl already outshines AOLserver/(O)ACS: migrating data from two different types of databases (Oracle to Postgres, for example), because nstcl's database api doesn't force you to fall back on the AOLserver ns_db api for the second database. :^)
