It's been a while since I wrote my own UI library, but here's my opinion. Take it with a grain of salt:
I am not in favor of preferred size, min, or max. I think this pollutes the logic. Consider two child items side by side, both with preferred size of 100. Container is resized to 150, what is the size of each child item? If your answer is 75, then why bother with preferred size at all? Why have a parameter at all only to be ignored?
Instead, each child should be responsible in its own proper rendering and logic in any size. By any size, I mean even down to 1x1 pixel. No minimum size, no maximum size. You have a button, that button better works even when its 1x1. You have a radio button, it better works at 1x1.
You can enforce minimum size at the container level, but child item (which cannot contain another child) should be able to handle any size. Object positioning should be handled by the container, and any items should not dictate to its container how it should be positioned, neither preferred, min, nor max.
The reason why is that I have worked on some custom UI library that follows this Java's swing approach, and it has these preferred size, min, and max etc, and they dictate the way the container align and position its children. It's hard to resolve conflicts at the container level if the child items can dictate to its container how to position itself. One child say my min is 100, another say my min is 150, and container is resized to 200, which one should you resize?
It gets worse if child items are engineered with these preferred, min and max in mind, that certain logic starts to fail when the size goes beyond or lower than these arbitrary thresholds. "Since my size won't ever go lower than 100, right?, so I'll draw this 5x5 important UI element at exactly the 95th pixel" Guess what, your width is now 80, and that important UI element is now gone. Great.
So, no min, max, or preferred at all. As a matter of fact, maybe let the container tells its children their size.