Tclkit contains, now and always:
Tcl, Tk, Incrtcl, Metakit, and TclVFS.
None of these will go away or change in ways that breaks normal use.
The TclVFS package is part of Tclkit, but it only contains a very minimal set of drivers: m4vfs and zipvfs.
The starkit package is a pure-Tcl package, needed to support starkits. The Scripdoc package remains in tclkit to support older "scripted documents", but is deprecated.
There are a few Tcl wrappers around internal commands, which are stable as well:
These are in fact set up to use Trf and Memchan, but are overridden in tclkit to use zlib and rechan instead.
There are a few compiled packages, i.e. zlib, rechan, and librarypath ("pwb"), which are artifacts of the current implementation. These may change, and are considered internal to tclkit. You should not call these directly, but use the calls described above.
Older bits and pieces of tclkit, i.e. md5 and "pink" are no longer included.
On all platforms, tclkit contains all extensions which are part of the "core distribution", i.e. what you get when you download Tcl + Tk, and build them.
Tclkit contains only 5 basic encodings:
ascii, cp1252, iso8859-1, iso8859-2, macRoman
This approach is still *far* from perfect. It will be resolved when a better way is found to deal with custom encoding sets.
The whole reason for not putting lots more real nifty things in tclkit, btw, is that tclkit is intended to be a fixed point for Tcl/Tk scripting. Even if some will see it as a subset of what they need, I hope it can be the subset that makes a huge range of solutions possible as is. With everything else placed in starkits, starpacks, plain files, whatever. And for those who don't want to work with these compromises, there are always the sources and other distributions.
For that reason, I chose to leave out the less final drivers of VFS, and lots of encodings which would add greatly to the total size. It's a compromise. Always has been - always will be.
Note: I reserve the right to change any part of tclkit from being statically linked to being a shared library, included in the VFS part at the end of each tclkit. This is nothing new: Tk is statically linked in some builds of tclkit, and a shared library in others right now, for technical reasons, and hardly anyone notices (apart from some imperfections which I've started to iron out). This will not be done lightly, robustness will remain a top concern.