> Because now it's obvious both what I want and why FramingLayout isn't it.
That was pretty much my reaction to FramingLayout, having already seen Auto Layout, yes :).
> express things like "the bottom frame of X is equal to the height of its content"
I actually did this—there is already a "preferred extent" mechanism (see #usePreferredExtent, #preferredExtent, #calculateExtent:), which the simpler LayoutManagers "propagate" correctly (that is, a container's preferred extent is based on its contents). It isn't particularly difficult to add #preferredView{Top|Right|Bottom|Left} modes to FramingConstraints—analogous to #fixedViewWhatever but based on the preferredExtent. I'll have to see about contributing those changes at some point, along with filling in some gaps in controls knowing how to calculate their preferredExtent. Note that FramingLayout itself I believe does *not* know how to calculate the preferred extent of its own container, so you can only have one level of it and have everything calculate nicely.
> "the top frame of X is the bottom frame of Y"
This is halfway possible as long as X and Y are immediate siblings (a View's collection of subviews is ordered, this is baked in to Win32)—there's a #fixedPrevious{Top|Right|Bottom|Left} constraint. However it can only propagate forwards, not backwards (there is no #fixedNextWhatever), and more complex interrelationships are not possible. This is the point at which the problem outgrows FramingLayout's simple, single-pass algorithm, and a proper constraint solver like Auto Layout becomes necessary.