Sure. Here are some possibilities:
1) GnuTLS bindings, including adding to Swazoo support for serving
HTTPS. Other common libraries, such as GD, GSL or Expat would be
interesting. In a project application you probably want to propose a
coherent set of libraries to work on, with an example of an
application that would tie them together.
2) Work on the GUI. You could write a Gtk or Blox back-end for
OmniBrowser, or add the ability to develop in the GUI and sync the
files on the file system.
2a) As part of this you could also develop a system to port changesets
from other Smalltalks. The idea is to have a merge-like command that
takes two foreign source code files (e.g. from SqueakSource) and
merges the code into a GNU Smalltalk source file.
2b) Or, you could implement a "remote browser", i.e. something that
could browse an already running system. In other words, the
view/controller and the model would reside on two different instances
of the VM. This requires implementing or porting some kind of
distributed messaging system.
2c) The same, for debugging. Investigate possibly if the protocols
that are used by Java debuggers are suitable to Smalltalk.
3) Work on command-line tools. You could port parts of the
Refactoring Browser and make a command-line version of Smalllint for
example.
4) Create a build tool that allows one to coordinate builds with
Smalltalk scripts, like Rake or SCons (see also
http://smalltalk.gnu.org/blog/bonzinip/sake-rake-smalltalk for an
example of what I mean).
5) Add a GNU Smalltalk backend to SWIG.
6) Implement better strategies for block closures in order to improve
performance.
7) Build a continuous integration server using Seaside, with code
reports. This could have many directions: building an interface to
version control systems (svn, CVS, git) that can be used from
Smalltalk, analyze what problems would limit the uptime of a web
application written using GNU Smalltalk and Seaside (memory leaks,
etc.),...
8) Write an Eclipse front-end for GNU Smalltalk.
Paolo