Priority list as of 0.9.11:

1. EAP support using external EAP server
2. merge dictionary rewrite (compatibility!) from pre1.1, including
   tagged attributes and bi-directional generic attributes (Unknown-232)
3. Language changes: 
   * harmonize del, delall, F:, REQ: and REP:, := and = into d:, D:, f:, 
     rep:, and n: prefixes and allow them to be used in the ASCII interface as
     well (req: becomes default in language, regardless of operator; n: means
     create new instance, even if one exists; allow explicit req: in ASCII
     interface), giving it more complete access to both lists. The ASCII
     interface may also get a flag to send both lists to the module, prefixing
     the current reply list attributes with 'rep:'.
   * the 'everything a list' design as discussed in February '05 with Brian
     Candler
4. Dictionary-based attribute encryption for those brain dead tunneling 
   attributes that I implemented on Cistron years ago
4a. Upgrade internals; replace some old stuff with routines from evblib,
   most notably rings and type conversion.
5. Generic VM state storage to tie in with generic event-driven version of
   the behaviour expression. Instead of having a single entry point (for new
   requests), we'd have an entry point for each 'incoming data' event (new
   request, proxy answer, data from module). Coupled with a generic auto
   garbage collected state storage for VM contexts, keyed on arbitrary strings,
   this can be used to implement and experiment with multi-message 
   authentication types, including challenge-response schemes such as EAP.
6. UIDs: allow a uid to be specified that takes effect after starting the 
   modules; allow each module to use a different UID as well.
7. (earlier) Merge contributed package for Debian
8. Better, faster, more flexible logging module (in C and supporting per-entry
   variable paths)
9. Berkeley DB and cdb modules
10. DNS resolver module that returns strs for ips and vice versa
11. MSCHAPv2/MPPE support (using new base64, sha1, ntdes operators)
12. Perhaps add rule-based language instead of free-form expression;
    look at mod_rewrite's and iptables' faults and benefits.

And of course always:

* Better documentation
* More sample configuration/behaviour combos

