The pattern that Casey describes is also possible within this model, because the API is layered in the same way, with high-level APIs simply being fast-path compositions of lower-level APIs. The feature flags are just fast-paths for a supported set of feature combinations, which itself is a much larger set than the set of “widget kinds” (which would simply poke into that set).

Feature flags aside, builder code can consume input and render graphics arbitrarily. It can take full control over the building codepath in the same way. The feature flags are not the only means by which builder code can provide the effects it needs; they are just options for standardized fast-paths that would be duplicative to rewrite or maintain (e.g. clicking/dragging behavior).

Nevertheless, your mentioning of the position as “library user” is why I do not think UI core code should be packaged within a library for general application development; or, I at least don’t think it’s that simple. Sometimes you do need standardization across multiple applications (e.g. picture yourself as an OS vendor). If libraries were to be provided in this case, I’d say that the ideal decomposition is not obviously “UI library”, and instead it might be that the OS provides simple building blocks that offer controls for its features (accessibility, for example), while allowing composition with user code. (On top of this, you might still have high level APIs that are also just compositions of low level APIs).

This is why I wrote a post on ditching the idea that there is any one layer that defines “what a widget is”—instead, there is just a code code layer that has some building blocks for certain patterns of data transformations. In my experience, there’s rarely a single layer that can totally define a high-level idea; the desired high-level effect must be achieved through composition of multiple layers.