The main current priorities of Kawa are making it fully compatible with standard (R5RS) Scheme, implementing debugging facilities, and making the ECMAScript support usable. The major tasks for R5RS-compatibility are the rewrite to support general continuations and tail-calls, plus a redesign of how macros are implemented.
Implementing ECMAScript requires moving Scheme-specific code out of the Kawa core. We also need a more general interface to plug in new parsers, pre-defined functions, data types, and output formatting. That will make it easier to add new languages and dialects. Of special interest is re-implementing some of the ideas and syntax from my earlier Q language [Bothner88]. These include a line-oriented syntax with fewer parentheses, and high-level sequence and array operations (as in APL).
Also of interest is support for Emacs Lisp. This would require an extensive library to implement the Emacs data types (such as buffers and windows), in addition to the challenges of the Emacs Lisp language itself (it has different data types and name binding rules than Scheme), but may be a good way to build a next-generation Emacs.
There is very preliminary threads support in Kawa.
It provides an interface to Java threads that looks
somewhat like delay, except that the delayed expression
is evaluated in a new thread. (The model is similar to to the
“futures” concept of MultiScheme [Miller87],
but there is no implicit force, at least yet.) Some
of the core classes (such Environment
and Translator) now support threads
with optionally separate top-level environments.
An interface to graphics primitives is needed. The new Swing toolkit seems like a more powerful base then the old Abstract Windowing Toolkit.