For example, I may think of BViews like sheets of paper which I can stack on a table (the parent view). The last stacked paper is then "naturally" the "front" paper. I may also think the "front" view is the first added child (as in front of the list), which gives me the opposite interpretation, but it's just in my head. The documentation just says it's undefined. It is actually important to avoid these layouts. It was much more the case on BeOS, on Haiku the drawing order is even deterministic.
Funny, I think of sibling views as neighbors which can be concurrently processed to improve rendering performance ;-)
This way, naturally, the drawing order doesn't matter. And needs to not matter...
Overlapping would need to be detected to prevent obvious issues (well, obvious to anyone that knows a thing or two about MT-programming, I suppose).
--The loon