Jerome just published a few suggestions on future developments, and features he would like to see implemented in WPFF. Here's my position on these issues, as usual I welcome any feedback or attempts to make me change my views.
1. Templates I have never liked Smarty, even though I knew about it since the first proposal and even stated my views on the matter (can't find the link anymore, sorry). I won't switch to another templating system for some time, and when I do it will be my ZPT implementation. ZPT is simply the best templating engine available, writing for it is a pleasure (of course, Python has something to do with it). I know there's a PHP implementation already available, and even though it is used for MediaWiki (the Wikipedia Wiki engine), I don't like it very much and won't use it in my code. As for the question of leftover template variables, it's a feature not a bug. If you see something like {my_variable} in the HTML output it means there's a bug somewhere. And if you don't like this behaviour you can just change the Template constructor arguments to hide missing vars:
$tpl =& new Template($path, 'remove');
2. Missing Features As Jerome says, new feeds are very easy to develop requiring only a new template. I will add them in a future release, even though they're not essential since RSS2 is enough for most needs.
WP get vars/permalinks compatibility is not at the top of my list either. I need WP compatibility only at the DB level, I don't much like its architecture and have no desire to delve into layer upon layer of code every time I need a new feature, only to preserve compatibility. And in the long run, I will write a new backend based on a radically different DB schema, and WPFF will become its frontend. If somebody wants to add WP compatibility though, I will welcome a patch.
Search is a feature I will add soon, as we are discussing adding it to our blogs. It won't be very sophisticated (people use Google anyway most of the time), and it will definitely use MySQL's full text functions. It will proably be implemented as a plugin (which will require a slightly more sophisticated hook than the ones already there), so that people that don't need it can skip the relevant code and keep their frontend a bit faster.
The last one (render content once) is definitely on the top of the list, but will be implemented in the new backend. I totally agree with Jerome in that complex things should be done once and stored in the DB, as it's pretty stupid to transform thousands of times content that changes once or twice in all its lifetime. What I will do is store the "raw" content, its "content-type" (text, HTML, Markdown, etc.), and the rendered version for each post.
3. Caching Caching will be the last feature to be added to WPFF, with something similar to PEAR's Cache:Lite. It will probably be a plugin at the page rendering level.