I'm finding that the update setup isn't adequate in some situations.
Currently, the update setup works in a top down way. Parents give position and sizes to their children, then they let their children do the same to their own children, and down it goes. Parents take decisions based on their children's preferred sizes. This is how it's done in a managed UI.
It is also possible to create a UI in an unmanaged way. In that case, it's up to the components to manage themselves. (The first parent element in a managed UI is usually unmanaged.)
A problem right now is that in order for a parent to take good decisions, it's children need to be aware of the size that they want to be. The update setup current works in a top down way. The problem becomes obvious if you consider nested panels. The top panel might ask a child panel's preferred size, but that panel might not yet know until it also runs it's own update setup.
Instead, a new function could be added to the API. It would get called before update setup and it would work from the bottom up. This would let the bottom components figure out which sizes that they want, then their parents can use that info to also figure out their own preferred size. When all the preferred sizes have been figured out, then you call update setup. This would make the algorithm start from the bottom up, then back down the other way.
You can think of this new function as separating the layout's dream world from the layout's practical world. In the dream world, things can be any size. You go up the chain, all the components are happy, then you reach the top component for example a screen panel. A screen panel starts to introduce limitations for example, nothing can exist outside the screen. Then we go back down and fix all the components.
All of this might sound complicated, but it's really not and it makes it much easier to reason about each component's place in the UI world. The main problem with that is to figure out how to not add too much overhead. Are we now doing twice the work?