I don't agree fully with the example.
The process definition is static.
At runtime, instances are created from this definition (ie. class-object relation). If I need metadata, I put process variables on the instance before starting the process. Regional managers can then be picked based upon these variables.
Changing this concept is bound to break some older implementations and is something that must be well-thought about before changing it...
The point is, that metadata that applies to may Executions should be externalized a separate document. In J2EE you find this in the various deployment descriptors. The implementation i.e. the Servlet or EJB is seperated from that metadata.
I put process variables on the instance
if "you" put process variables on the Execution, you binds "your" implementation to the processing of this metadata. Every client of the API would have to invent its own meta data processing if this is not generalized at Engine level.
Lets defer this discussion until I can show you a proposal in code. This is when http://jira.jboss.org/jira/browse/JBPM-1325 is done.
You can then take that proposal and comment/improve on it.
This is true from the engine point of view, but for many of my projects the engine is not my entry point. If you can remember, this is something I showed in Dublin with the 'process access object - PAO'.
Normally I have an interface which defines operations on the engine. All the clients that use this interface will set the same process variables. Off course, that's my (main) usage of jBPM, but I see many people do the same thing.
Joram is correct. In the demo system we have the way process are started is also done by a kind of PAO. Passing metadata to the engine is generic, but the way it should be used while instantiating a process differs a lot between systems.