I just wrestled with the semantic layout myself.
In my case I was trying to get two containers on top of the model. After a while looking at the layout code I figured out how to make it work.
The order of the container definitions matters (at least for putting stuff above the model). This is because the top of the model is only really adjusted on the first iteration. That is probably not the intention, but it is how it is currently working.
The gory detail is:
In the first pass at positioning of the containers the 'top' of the topmost container needs to be a negative number that is equal to the amount you want the modelTop to shift down.
This can be done by defining the container closest to the model (lower-container) first and specifying it's bottom to be 'model.top'. Then define the container above that one (upper-container) and specify it's bottom to be lower-container.top. This will result in a computed top for the upper-container that is the negative of the totalHeight of the two containers. This then causes the modelTop to be shifted down by that much.
If you specify these definitions in the order which you want to them appear, then it doesn't work. When the 'top' of the upper-container is computed the top of the lower-container won't be known yet, so it will default to 0. This will make the computed top of the upper-container to be 0 - upper-container.outerHeight. Then the top of the lower-container 0 - lower-container.outerHeight. At this point the modelHeight is shifted only by the minimum of those two values and it is unlikely it will be shifted again on the second pass. Sorry it is too hard to describe why that happens, but if you put a debugger statement in you can see it happening.