Just one side point - when modifying the original example to add nesting, there was
a problem with the line...
   view circleLayout executeOnElements: (view raw elementsFromModels: (1 to: 5)).

which I don't know understand why #executeOnElements was required since just...
   view circleLayout

seemed to work just as well.

To summarize results shown in the graphic, for nested elements, the following are broken:
RORadialTreeLayout
ROSugiyamaLayout
ROHorizontalTreeLayout 
ROForceBasedLayout
ROScatterplotLayout
ROTreeLayout

The following appear to work fine nested:
ROGridLayout
ROVerticalLineLayout 
ROHorizontalLineLayout 
ROBottomFlowLayout 
ROFlowLayout 
ROCircleLayout

In addition, I guess it gets a bit tricky when edges cross the boundary of parent elements
- particularly with the force based layouts.  I remember bumping into an issue with
Mondrian where the nested elements were dragging the parent elements over the top of
each other.  A brief thought on this is that edges that cross parent boundaries should
be handled in two parts.

1. Outside the parent - the edge should "act" in the layout of the parent that is common
to the child-elements at each end of the edge.    

2. Inside the parent - the point where edge crosses to the border of parent becomes
a proxy for the other end of the edge.  This way the "distance" that multiplies the
force has less impact on the local layout within the parent.

So in the attached image, for the edge between B & G, the force layout will try to
bring point 10 & 11 together, but not point 9 & 12.  When 10 & 11 are close, the repulsion
between C & H should dominate rather than still trying to bring B & G together.  

Similarly, for the edges between I & A and I & B, once A & B are up against the bottom
edge of C, the small distance between 1 & 2 and 5 & 6 should allow  repulsion between
A & B as well as the bottom edge to dominate - rather than the greater distance between
1 & 4 and 5 & 8 forcing A & B to overlap.  In addition, the position of I within K
should not be affected since K does not have a circle layout.

This brings me to another passing thought... I think it is a little undefined what
happens if you apply one layout to some child elements of parentA, and a different
layout to other child elements of parentA. Perhaps rather than applying layouts to
a group of elements (eg ROGridLayout on: el elements), a layout should just be applied
to a single element, which arranges all elements contained there-in (eg ROGridLayout
on: el). For the case above, this would require the two sets of elements to be part
of subParentB and subParentC, each having different layouts.

btw, I can't remember seeing any cases where I haven't applied a layout to all child
elements of a node.   

!So there are likely lots of complications I haven't considered and more than can be
dealt with in a single issue, I'm just brain dumping in proximity to the topic that
sparked these thoughts. 

We will work on this thread as soon as we close the one of translation shape.
Thanks for pushing!

I am not sure to fully understand this issue.
TreeLayout works well when embedded.

try the following:
-=-=-=-=-=-=-=-=-=-=-=-=
    outterNode := ROElement new + ROBorder blue.
    elements := ROElement spritesOn: (1 to: 5).
    outterNode addAll: elements.

    rawView add: outterNode.
    rawView addAll: (edges := ROEdge linesFor: (Array with: elements first -> elements
second with: elements second -> elements fifth with: elements second -> elements third
)).

    ROTreeLayout on: elements.
-=-=-=-=-=-=-=-=-=-=-=-=

I've added this example in ROExample>>nestedLayoutOn: it is therefore accessible from
the example section in Roassal

Is this still an issue?

I think it is still an issue but I don't have time to explore it fully this month. 
 Can it rolled over to version 4.8?

Please take a look at this. Otherwise, we close it.

I don't have time right now, so close it.  Later if it turns out to be a problem longer
term I will get more data before I would ask for it to re-opened.