And yes, I know this can all be done in the generated forms, but so can "access=read, write, required" so that will not be accepted as a reason for *no* ;-)
in 4.0, for jPDL i hope to pursue the following:
1) jPDL in bacwards compatibility mode. old jPDL processes will be deployable in jPDL 4, but the databases will probably be incompatible.
2) jPDL 2. There are a lot of improvements that can be made to jPDL. More direct support for other concurrecy models, hierarchical sub-tasks instead of the flat list we have now, process annotations, static variables, variable declarations, etc
3) expand jPDL 2 with many functional node types. E.g. like the mail node we have now or with web service invocation nodes. also we might think of modelling external triggers. E.g. transactions might be external triggers or internal events. When those triggers are explicitely modelled with input parameters, it's possible to generate java beans or web services from that (like BPEL does).
This last focus would allow us to cover a big part of the BPEL functionality with free graph modelling, easier integration between services and java and other node types,...
But with out limited resources, we'll have to take it step by step and see where we end up...