Rather than define specific features for the core language, it should
focus on inter-operability. For example, the core language should use
something like the OMG's version of 'IDL' to define interface
specifications. Automated tools could then generate stubs and
interface code. This simplies the process of 'importing' functionality
into the interpreter.
Much of this has already be demonstrated by the 'dish' interpreter
that comes with Fresco.
The remainder of the interpreter should be a simple Scheme-like-core
(static scoping, dynamic typing?, exceptions, garbage collection) --
the external syntax could be anything you want, but you need the
internal support before worrying about the external mechanisms. The
scheme-core is efficient and simple to evaluate, and there are a
number of public implementations. The Scheme2C system from DEC would
be a good start.
This would give you a lot of possibilities:
(1) The external syntax could be compiled to the core, and the
core and the program could be linked with an application if you
want a GUI builder w/o worrying about the users being able to
extend the application dynamically.
The "compiler" for the external syntax could provide considerably
more information and debugging information that the TCL
interpreter, because you wouldn't link it into applications.
The interpreter could be wicked fast.
You can also take things a step further and compile the 'core'
into a language like C, as the Scheme2C system does.
(2) You could build an parser/interpreter for the external language
that could be linked into the application if you want the ability
to extend the application.
(3) You could have a stand-alone "wish-like" tool that bundles the
interpreter and multiple utilities into one commonly-used tools.
By defining and documenting the internal core, you would let people
produce other front-ends to that language.
None of this is all that hard to do, it's simply doing it in a way
that's portable & documenting it that's hard.