I ran into a typography inconsistency in a production SwiftUI interface.
Several adjacent labels used the same .headline, the same width, and the same Dynamic Type environment. Once minimumScaleFactor was involved, though, they stopped looking like one typography system.
The obvious explanation was that each Text was solving fitting independently, but I didn't want to stop at "that seems plausible."
So I reduced the production case to plain SwiftUI first. The visual behaviour reproduced without any custom Layout instrumentation.
Then I built a small layout probe to see how systematic it was.
The main run covers 100 conditions and 500 validated measurements across container widths, Dynamic Type sizes, and minimum scale factors.
The interesting part isn't that minimumScaleFactor shrinks text. That's documented.
It's the design consequence: a shared typography declaration such as .headline does not guarantee shared visual typography once each label is allowed to solve fitting independently.
One important limitation: the public SwiftUI APIs used here expose layout proposals and reported sizes. They do not expose the actual internal glyph scale, so I don't claim to measure it.
I also kept an invalid first threshold run in the repository. The harness was accidentally propagating a zero-height parent proposal, so I excluded that run, corrected it, and reran the experiment.
Article:
Reproduction project and raw evidence: