Would it be possible to implement the Task UI entirely as a REST client? That would make it much more flexible and useful, and it would eliminate a lot of confusion (at least for me). I’ll try and explain. (Sorry, it’s lengthy.)
I spent several days wrapping my head around just how the UI apps are interdependent, and how they interact with the REST war. I know Activiti/Flowable well enough to understand its mechanism (I remember being awestruck by Tom Baeyens’s presentation of his Process Virtual Machine over 10 years ago 
). The database defines everything, so connect two applications to one database and they share one engine. In a container (where one normally doesn’t flip datasources), this implies that a WAR is connected to a single engine from its moment of deployment – which has always been a bit of a hassle with the Explorer and REST apps.
However, in a very neat departure from v5, this doesn’t (seem to) apply any more to the Admin UI and Modeler UI. They don’t sit on the database of the single engine they control, but instead are stand-alone apps that use REST instead of JDBC to interact with outside engines. (One sore point: the Modeler’s deployment endpoint is hard-set server side; it would be neat if it were choosable, just as in the Admin UI.) So, the Admin UI and Modeler UI now use their own (externally irrelevant) databases, and have replaced JDBC by REST as their interoperation protocol with engines.
Sideline: Or have they? If I would connect Modeler to e.g. the REST war’s database, is then any modeled process immediately available in the REST app, i.e. without deploying it there over REST? I hope not; that would confuse the daylights out of me. But then why does the user guide recommend putting a shared flowable-ui-app.properties in Tomcat’s instance lib directory? Do Admin, Modeler, Task and IDM require access to a shared database after all? 
At least I was comforted to find that the Admin UI and Modeler UIs do not expose a ‘process-api’ REST interface that would enable deploying processes ‘on themselves’ – they probably could, if they include the flowable-engine.jar, but that would muddle things needlessly.
But then, why does the Task UI application provide a REST interface? Unaware of this, I had walked through the “Getting Started with REST” (Ch. 2 User Guide), then opened the Task UI expecting to see the deployed processes and tasks. Nothing? 
Oh wait, the REST tutorial operates against the REST war, and I haven’t pointed the Task UI war’s database.url to it yet. Will do later. But surely now I must see them in the Admin UI. Nothing?! 
. What’s broken?
It took me a while to figure out that the REST endpoints in the Admin UI are set to point to the Task UI. Huh, why would they? And why would the Task app have a REST interface at all? Like the Modeler and Admin apps, the Task app feels like a client. Functionally it is a client. You expect it to connect to a process engine (such as the REST app), not to be a process engine.
I know that technically there is no issue with having the Task UI war offer a REST interface and expose itself as both a client and an engine. Functionally however, I think the current out-of-box setup will confuse people – it certainly had me pull my hair out 
.
The perfect solution of course would be if Task UI were migrated from using JDBC to using the REST. I don’t know if the exposed REST interfaces are already sufficient for this, but that would truly be the be-all-end-all. The Task app would, just like Admin and Modeler, become a stand-alone client to use with any engine!
Thanks for listening (so long 
)
BTW: when I changed the REST URLs in Admin UI to point to flowable-rest/service (and changed the credentials to kermit:kermit), sure enough there were my processes! 
.