[Michael Schlenker] has very succinctly stated the need for a rich standard library for Tcl in several usenet postings

http://groups.google.com/groups?q=g:thl2123827996d&dq=&hl=en&lr=&ie=UTF-8&oe=UTF-8&safe=off&selm=c5mb9q%242pd6o%241%40ID-102549.news.uni-berlin.de

http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&safe=off&selm=c5n813%243913h%241%40ID-102549.news.uni-berlin.de

He says:

 Tcl has two competing groups in the discussion: The embedders that are 
 concerned about startup time, library size, memory footprint and things 
 like that on the one side, the 
 "batteriers-included-huge-stdlib-in-the-core" fraction on the other side.

 Those targets are impossible to reach at the same time.

 So instead of making it a problem, try to create a virtue.

 a) Let the embedders factor out as much functionality as possible from 
 the core into a modular stdlib

 b) Let the batteries group add as much useful functional as required 
 into a modular stdlib

... and ...

 - Integrated, cross platform build system (TEA or better)
 - Useful documentation, probably doctools based
 - Stubs enabled if at all possible
    (sometimes hard or near impossible to achieve)
 - Export their own stubs table if their functionality could be useful
 - BSD license
 - Provides fundamental extra functionality (Thread, msgcat, XML, ASN1, 
 TclX/Registry/ffidl/Twapi, KBK's localized clock, Datastructures, One or 
 more OO-Systems, RPC-Support, TLS/Crypto,... )

To which I [davidw] would add:

 - The package should have a maintainer.
 - I would prefer to have one and only one OO system.  Experimentation in this area has gone on for long enough.  We need to provide something practical that works, for the "get it done" crowd.