The case where the subtract method is called with a duedate expression and reference date that resolves to a date in the past is handled by throwing a JbpmException ("duedate <date> ends in the past"). While this may sound like a good decision in theory, it is problematic in practice.
As a user of the API it means I have two choices when calling the subtract method. I must either resolve the calcuation myself before calling the method, to avoid the exception, or I must catch the generic JbpmException and decide on a duedate myself not knowing what went wrong.

When someone requests a date that is in the past in this way there's basically three options:
1) Let them have it. - This seems like a silly solution to me, duedates in the past doesn't make sense.
2) Throw an error. - In this case a specific exception should be thrown so that the user of the API can know why he got an exception.
An alternative to today's solution is to throw a less generic exception, maybe 'DueDateIsInThePastException' or IllegalArgumentException.
3) Return the current date, i.e. return Clock.getTime(). - Optionally a warning that the date was overriden to not be in the past can be logged, but this seems unecessary to me.

Attached patch implements alternative #3 (against trunk/revision 6208), which I believe is the best choice.