Actually I've learned a lot about workflow, too, recently. Dave's right that you can use it behind the scenes, which is what I'm doing in the dotLRN events package I've been working on. Lars left us a fine foundation to build on, and we should talk to him about improvements and tweaking after we get this first release behind us.
It is very important that workflow be integrated into ETP if we want it to grow to become a general purpose CMS. One thing that workflow gets you is the ability to change it - add or remove authorization steps, etc - without changing the code. This makes it much easier to tweak something like a CMS to fit the editorial process of an existing business, for instance.
Also, users get their "stuff" displayed to them in a centralized, "tasks todo" page in the workflow package. If all packages used workflow to manage tasks then users could visit this one, central place to see what's pending. "Fix this bug!" "Edit this page!" "Cut this release!" etc. If you provide custom "panels" (templates) and assign them to your tasks, and drive your package from workflow too, then you can present the same forms to the user regardless of whether they get there from within your package or from the workflow "tasks todo" page.
And the Petri net pictures drawn by graphviz provide excellent documentation.
I would say this is a requirement, not an option, for many potential clients.
I find the idea of releasing an editor that only works with IE distastful for a project like ours, so I agree with Jun that supporting Mozilla would be a very good thing to do. I'd even put it more strongly than that. What's involved in supporting Mozilla?
It sounds like Jun still has a bunch of clean-up to do, and of course, the Oracle port, but overall this sounds pretty exciting!
