This is just for my understanding - the reason this exists here in addition to being in should_drop as well is because of the Default state which would mean that the should_drop will return false. But, we don't need to match against EndConditionalContent as it'll be taken care during the should_drop check.

I wonder if this could be simplified to only have a counter where any value > 0 indicates that we're in "if_group_breaks" and 0 indicates that we're outside of it. Or, do you foresee any other states that we might want to track in RemoveSoftLineBreaksState?

We could probably just use one usize for it where 0 indicates that we're inside an if_group_breaks if we change the implementation to start the level at 1 instead of zero.

However, I do like the explicit state because it documents what's going on here.

I'm fine with the explicit state, I just found the multiple usages of incrementing but only a single usage of decrementing the value a bit confusing. I had to look at it a bit closely to understand why this is the case.

I just found the multiple usages of incrementing but only a single usage of decrementing the value a bit confusing

I don't think that would change by switching to using an usize instead of an explicit enum (we could "hide it" by using saturating_sub).

There was actually a bug that we called increment twice in some cases. I refactored the code a bit