(this is in response to comment 11, I hadn't read comment 12 or 13 when I wrote this)
Great counterexamples for getting to the bottom of this. It might finally be starting to crystallize in my mind. So, explanations:
For the original cats example https://jsfiddle.net/dgrogan/1a06xyjw/1/, I think the spec intends for the top case to have no cyclic percentages because of this github comment where I shared the same fiddle. fantasai and Tab both immediately said there is no cyclic percentage in the subsequent 3 comments. (I'm treating their opinion on this as equivalent to the spec's intention)
So in the rest of this comment I am assuming there are no cyclic percentages in the original cat example while trying to explain Blink's very confusing behavior in the counterexamples.
Counterexample 1 (top case in the fiddle)
There are no cyclic percentages in this fiddle, but a Blink bug affects the content size suggestion.
Blink bug 1: Blink is overaggressive when compressing. Blink makes "semi-replaced" (but NOT replaced) elements resolve % width against 0 for their min content even when there is no cyclic %. [code]
So in this example, the min-content of the input is 0px because it has width:100%. And content size suggestion = min-content = 0px (modulo any input-element specific floor). The input's specified size suggestion is 100px. So the input's automatic minimum size is min(0px, 100px) = 0px. The orange box also has auto min-width:0px so they end up 50px each.
I suspect that the spec's compressibility notion came about by trying to reverse engineer this Blink behavior I labeled 'bug 1'. Before flex arrived, I think the difference between Blink's behavior and the spec's definition of compressible was not observable. I think it would be ok to specify bug 1 if fixing it has compat problems.
Counterexample 2 (top case in the fiddle)
There is a cyclic percentage AND a different Blink bug affects content size suggestion.
In Blink, replaced (but NOT "semi-replaced") elements resolve % width and % max-width against 0 for their min content contribution, not for min content. I think that's per spec so far. Blink is overaggressive about this too: this happens always, even if there is no cyclic percentage, though I think this overaggressiveness is not relevant to this example. [code]
So in this case, the image's width:100% resolves to 0px for the image's min content contribution. That's why the image doesn't contribute to the min-content of the container and hence why the container has width 100px, where the 100px comes from the orange square.
Blink bug 2: Blink ignores the Note that comes right after https://drafts.csswg.org/css-flexbox/#content-size-suggestion that says the content size suggestion is a contribution. Blink just uses min content as the image's content size suggestion.
Because of bug 2, the width:100% on the image is ignored for the image's content size suggestion even though the spec requires the width:100% to cause the content size suggestion to be 0. and the image's content size suggestion ends up being the images' min content natural width of 100px. The specified size suggestion is also 100px after resolving width:100%, so the automatic minimum size is 100px. So because the container has width of 100px, its entire width gets allocated to the image, and the orange square gets width 0px.
Contrary to bug 1, I think Blink needs to fix bug 2 and the compat damage will be manageable. Fixing bug 2 means that the cat and orange square at the top of counterexample 2 will each be 50x50, which matches Firefox 90.
So, that's the analysis of Blink's <expletive>-ing logic for these cases.
From what I could tell, TYLin's patch under review changes behavior for cases that are not affected by either of these Blink bugs. TYLin, is that your interpretation too?
Again, your counterexamples are great. If you find more please post them.