Disclaimer: I am not a T user, just an interested bystander who has
been reading the exchanges on T-Discussion for a while and has had a
lot of experience with a couple of other Lisp systems.
The outstanding thing about T, in my view, is that it is the one and
only Lisp dialect that has *both* an existing, supported implementation
with a significant user and support community *and* a strong commitment
to the conceptual simplicity that might make it possible to produce a
manual of finite size, tools that manipulate programs and really work,
some hope of drawing on the large body of work on analysis and proofs
of algorithms, etc., etc. (All other "real" Lisps have hopelessly
muddy semantics, and Brian Smith's reflective Lisps aren't real yet.
I'm not including ML because even though it has a great deal in common
with Lisp, its flavor is quite different.) This quality is, in my
unsolicited opinion, so valuable that it justifies tremendous
caution in adding features to the language. I also happen to believe that
a system cannot evolve coherently if more than about 3 people have
responsibility for making all significant decisions regarding it.
(I have a number of examples in my experience illustrating both
sides of this statement -- i.e. systems designed by small groups that
turned out well, and systems designed by large groups that turned out
badly.) For that reason, I'm willing to live with some rough edges
and instability if I have confidence that the person(s) at the helm
are steering in the right direction, which in the case of T I do.
I don't have any good solution to the problem of living with features
that have been added temporarily to a system to answer pressing
needs, pending greater clarity about how to address those needs
properly. I can only recommend the pragmatic solution, which is to make
sure that when something better comes along, you won't have too much
trouble finding the places you used the interim feature. (Tools can
help here.)