Page flow versus process flow

I started noticing that in a number of RFP's around BPM-suites a requirement start popping up, that can possibly create a lot of mess.

Requirement: "When a user is working on a workflow task, and finishes it through the task window, and the process engine determines that the following task in the same process instance is to be done by the same user, the presentation layer should automatically lock and open this task, without the user going back to the inbox".

Hm, it sounds like a logical and user-friendly requirement. But in already two technical projects, based on different BPM-technology, we have been trying to solve this and had difficult issues.
One of the key problems arising here, is the mix of two metaphores: the MVC design pattern for task based user interaction and the MVC design patters for workflow/process.

Because, suppose a BPM solution supports the stated requirement, well, then it won't take very long and then someone will happily say "he, but than we can use our BPM tool to model user interface flow, e.g. screen 1, screen 2, screen 3 or 4, including all business rules". Sounds nice. But don't go there....
Why?

1. Technical issue.
In a solid architecture, user interface and process engine are decoupled with clear interfaces. User interface can use the process engine API to...
- get inbox of tasks
- claim / open task
- park / pause task
- report task ready

Most BPM engines do not support an API call, where in one transaction, one can signal a task ready, let the process engine create the next task, and ask that task immediately if it's for the current user.... It means that if a user reports a task ready, and the user interface needs to know if the following task is for the same user, some type of polling needs to be done (because you do not want to have knowledge in the user interface about the process, aka ah, it was task 5 in process B, so than I know task 6 will be for this user again - this would give maintenance on too many places...)
Pooling would be tough - the user interface does not know: IS there a next task? When will it be there (the process engine might be busy)? When it's not there, does it mean there is no task in this process instance. Etc. etc. Difficult stuff.

2. Logical issues
What is a page? What is a task?
If you start mixing these things, projects could become very complex and you end up using technology for something it is not meant to be used for (as of yet...)

In my opinion is a task a logical unit of work, to be done by one user, in (preferably) one go.
It could require a user interface, consisting of multiple pages or windows. With complex business rules. But these are MVC task/presentation data business rules.