The TaskManagement in jBPM is what you need for a lot of "Task-enabled-applications". So I faced this requirement a couple of times:

- Create AdHoc-TaskInstances in the process, not related to a special TaskNode, but related to a ProcessInstance
- Create AdHoc-TaskInstances not related to any process

By supporting this, you could use a generic tasklist-frontend (Webapplication or whatever) even to capture non jBPM specific tasks. This is a bit like BPEL4People, where you can create Human Tasks via an (WS-)Interface from your whole "SOA". So you need just one generic human task user interface.

Supporting this would release the people from the need to code their own task management beside jBPM, only because they have a few AdHoc-Tasks. Maybe the TaskManagement can be even used without the BPM part of jBPM. And if the integration with for example Outlook or Webportals goes on, this alone has already value for users (so maybe jBPM can be introduced through this backdoor ;-)).

Also I can image that you could connect TaskInstances and process states a bit more flexible, for example I faced the requirement, that you have a bunch of TaskInstances open during the first phase of the process (indicated by a wait state or super state) and the open ones should be canceled as soon as you leave this state. It is already possible today with having Tasks in a forked TaskNode, but this was more weird than it would have been (easier would be to create and cancel them via ActionHandler, but then they are not connected to a TaskNode)...

Just to give the idea, haven't already thought too deep into it...

Cheers
Bernd