I evaluate the PlasticSCM and I try to invent a trunk-based development and release management with it. I see the release management and the development as the separate repository for every separately versioned component that I have with top-level branches for the release management. So, I have component AAA trunk (I have to rename the default main branch because the development is trunk-based and not main-based) and AAA1.0 top-level release branch. I do not know if I do it right (as it is expected with the PlasticSCM) but so far, it is good for me.
The problem is that I find PlasticSCM workspaces a kind of cumbersome to handle AAA trunk I develop and AAA1.0 I support/maintain. I have gotten used to have separate workspaces to handle such situation in Perforce so I can have and, say, debug XXX/AAA/trunk and XXX/AAA/AAA1.0 simultaneously (I run two debuggers at the same time literally) and I am absolutely sure XXX/AAA/AAA1.0 will never contain trunk and vice versa. PlasticSCM binds the workspace to the repository. And it binds the workspace not to a concrete branch within the repository (it is always trunk indeed). So to be able to repeat the trick with the two debuggers I need to be very attentive while creating two workspaces and then switching them to the appropriate branches. I see that switching the workspace to a different branch may be useful for what you call child-branches but for a top-level branch, personally I would prefer a path on my filesystem that would never coincide with another top-level branch location.
But probably there is another, better way for the release management with the PlasticSCM than top-level branches.
P.S. And your arrows in the branch explorer are almost the blocker for me. I have read your explanation but I do not care if graphs are acyclic or not – I see the arrows as the dataflow and the fact that some of your arrows are the directions of the graph edges and the others (merges) are the dataflows hurts me nearly physically.