Some thoughts:
Very good and one of the reasons why we choose JBPM4 some time ago:
"based on a Process Virtual Machine (PVM), allowing the definition of multiple process languages on the same process engine"
In addition I would keep the interceptor chain. It really gives you a lot of integration options (different app servers, frameworks, transaction managers), all on a solid plug-and-play basis. In combination with the remote command executor this was one of the main benefits in our project.
A very important decision is how the process definitions are to be stored. Right now (jbpm4) processes are stored as XML in DB and the repository-session will ask the deployer to actually instanitate the process definition-object on every startup. This prevents dynamic ad-hoc definitions as they cannot be persistet (only one way is supported: from XML to process definition). JBPM could be a very good Workflow-Engine supporting Ad-Hoc workflows, if there was a mechansim to create and store defintiions via API.