Hey Ryan, good question. There are a couple things going on here: z-indexing and source order.
The z-indexing in Subform's tree is the opposite from how layers work in Photoshop, Figma, Sketch, etc. In those tools, the closer an element is to the top of the layers list, the higher its z-index. So a "bring to front" operation would move the element to the very top of the layers list.
Subform's tree works more like the default behavior of HTML, where elements lower in the tree are z-indexed above elements higher in the tree. So in your example, if the top element had the drop shadow, the bottom element would overlay it:
Your issue is a little trickier, though. If you move the box with the shadow above the other box in the tree, the z-index isn't the only thing that changes... the shadow box will also end up being the first thing in the vertical stack.
This is because the tree also controls source order: the order that elements are drawn in a stack.
This isn't an issue in Photoshop, Sketch, et al because they don't have layout engines. Elements don't have relationships to each other or orders, as everything is positioned absolutely. (Similar to how self-directed elements work in Subform)
Short term solution
As you've found, sometimes z-indexing needs to be independent of source order. Subform doesn't explicitly have a way to do that right now, but here's a couple workarounds for your example.
Make the status bar a self-directed element. A self-directed elements is out of the stack source order, so it can be z-indexed higher than the header container:
Another option would be to wrap the header element in another container. That container will have "clip children to parent" enabled by default, which will clip the header element's shadow:
Possible longer-term solution
It may be that—at some point—we want to provide a way for you to set z-indexing separately from source order.
This can be tricky to keep track of—if you've ever worked with CSS, you've probably found yourself giving up and setting
z-index: 999999; because you can't figure out why an element isn't appearing on top. Over time, this cruft builds up and it can be tough to understand the z-indexing in your design.
I like to use a central map for z-indexing when I'm writing Sass. All z-index values go into that map and I can then reference a key that makes sense to me, e.g.
z(header). It's easy to see what the layers are and change them in one central place to avoid conflicts. We could do something like this in Subform.
It's a bit similar to keeping track of a typography scale. Ideally, all the type in your design would draw from that predefined scale, so it's easy to make universal changes and describe the typography to the engineering team.