Note how the label view and input view have differing modes for desktop/tablet/whatever and for phone, but the button views take it one step further by also saying that it should care about portrait mode.
In the cancel button's instance, it only cares if it's phone AND portrait. If it's phone AND landscape, it uses the default properties. However, in the save button's instance, it has properties for both portrait and landscape.
At the moment, these are the only things that I care about, and I imagine other are similar. In general, we don't care about the actual aspect ratio, just when that aspect ratio switches from landscape to portrait.
Here in my opinion is the key test that our API has to be able to pass.
There exists an app with a header bar at top and a toolbar at the left, surrounding a main content area.
There are two width-based modes: when wide, the lefthand toolbar is always visible; when narrow, the toolbar shrinks to a collapsed click-or-swipe-to-open mode.
There are two height-based modes: when the window is tall, the header bar is broad and has lots of navigation content. When short, the header bar collapses to a shorter version.
The main content area then has four different layouts: large top gap / large left gap; large top gap / small left gap; small top gap / large left gap; small top gap / small left gap.
Whatever the API we end up with, it's easy to include handling for optional portrait / landscape tweaks per your work above, but how do we handle the main content area's need for four different layouts along two different axes?