> By either marking your data as const, or encapsulating mutations with private fields and public methods

That would seem to be making illegal states unreachable rather than unrepresentable, closer in spirit to "parse, don't verify".

GP seemed more worried about maintaining invariants in the face of mutability, so that's what my answer spoke to.

For modeling the data in the first place, just use the right combination of sum types, product types, and newtypes - that's not specific to functional languages. I'm sure GP knew this already without me saying it. Sum types may have been a "functional programming" thing a few decades ago but they aren't anymore.