And now you've baked your understanding of reality into your type system or your invariant contracts, you come to write some code that actually works with this

And now you've baked your understanding of reality into your type system or your invariant contracts, you come to write some code that actually works with this API and realize you've made a terrible mistake, because when you delete a user, you need to know which subscriptions to cancel, but you've already thrown that information away as soon as you called 'Delete()'. Maybe we should restrict you from deleting a user while they have active subscriptions? Well, that's easily accomplished with a C# invariant, a little harder to bake into the F# Type union. In general, though, it turns out you often need to be able to have objects in an 'illegal' state some of the time. "Zip code is a mandatory field" - but that doesn't mean you can't save your order form for later if you need to go and look up the zip code. It's generally best to validate objects as being 'eligible' for a particular operation, not to prevent them from being ineligible altogether - An object with no zipcode can be saved, but it can't be submitted. Structuring that sort of thing into a type system - while doable - is probably not idiomatic in either F# or C#.