"even with the help of types, you cannot design the whole type structures until you know the entire picture"
Sure you can. And like your design of anything else without knowing the entire picture, some bits of it will be wrong. A good type-checker - especially with inference - helps you find where you'll have inconsistencies in the assumptions you've made (usually before you've coded all the way to them), will give you a sense of the form of those inconsistencies, and when you change the types will point you at the code that needs to change in tandem.
I write a bit of Haskell in small projects but my background is largely Lisp/Scheme (the mud ball approach). I do admire hard-core Haskellers who seem "thinking in types". I wonder if there are good articles that tell how type-based approach helped dynamic development (meaning, lots of trial-and-errors, and rapidly changing spec, involving many components developed simultaneously by different programmers).
I assume you can encode implicit constraints in types, for example (suppose components form DG, you might encode dependencies to ensure restructuring graphs always satisfy them). Just like to see how it works in real life development.
I'm not sure if the description "hard-core Haskeller think[ing] in types" applies to me, but I definitely find the support of the Haskell type system hugely advantageous when I'm working quickly (and conspicuously absent when I have to sit down and write some Python or what have you).
My current project at work is a library of tools for parsing and analyzing SQL. I started out targeting one dialect and with a few analyses in mind. I think it meets all your criteria (lots of trial-and-error, rapidly changing spec, many components) but the last (I've done most of the development).
My approach was to start with a pretty dumb sketch of my AST, and then refine it as I learned things from trying to use it, trying to balance complexity against concerns of 1) keeping invalid states unrepresentable, 2) reducing unnecessary coupling, and 3) keeping inherent coupling explicit. With a reasonable amount of 1 and 3, changes could be made with far more confidence (paired, of course, with a reasonable test suite).
Going back to "learned things from trying to use it", it's a matter of walking out whichever is easier - types or code, and stubbing out the other until I have enough clarity that filling in the details there is easy as well. Quite often I'll build out the obvious code, come to a hard bit, and then I can ask the compiler for the shape of what it expects. Or drop in undefined and see if the result still builds. This can get me feedback long before tests could be informative.
The experience has been good, and I know I still have substantial room to improve over where I am.
Sure you can. And like your design of anything else without knowing the entire picture, some bits of it will be wrong. A good type-checker - especially with inference - helps you find where you'll have inconsistencies in the assumptions you've made (usually before you've coded all the way to them), will give you a sense of the form of those inconsistencies, and when you change the types will point you at the code that needs to change in tandem.