Ok: then how is the - at compile time unknown - state of a closure different from the state kept in an objekt?

I think we've officially reached the point of confusion. You've just paraphrased part of my own argument back to me as a refutation of what I said.

In answer to your direct question, the value stored in a closure is topologically bound to the execution tree more tightly than the value stored in an object. You can make an object, pass it to a function, and have it come back with a different value than it held when the function was invoked. You can't do that with a properly functional closure, though, because FP only allows information to flow up the execution tree in the form of return values. With a little thinking, you can also find differences between the ways closure values and object values move from one branch of the execution tree to another.

More generally, the closure obeys the FP constraint that all identifiers will remain substitutible within the same frame of reference, and the object doesn't.

Correct me if I'm wrong, but it seems you are claiming FP would promise a much simpler behaviour, by deliberately misunderstanding FPs design principles.

Okay, allow me to correct you: I don't claim that FP expects simpler behavior from closures.

I did note that closures, currying, and so on break the expected simplicity of lexical scoping, but those claims of simplicity aren't original to me. The idea that you should be able to learn the value of a variable, or predict the behavior of a program, from direct inspection of the code is one of lexical scoping's major selling points. That isn't a comment about FP itself, though.

I also tried to point out that closures and currying have enough power to simulate dynamic scoping, which makes it a mistake to say that languages like Haskell and Scheme -- which use lexically-scoped variables, but also support things like closures and currying -- are automatically immune to the problems of dynamic scoping. No, you don't get dynamic-scope problems from the lexically-scoped variables, but you can get them from closures and curried functions. The syntactic sugar will look different, but the underlying problem will be the same.

Of course, you can avoid rolling your own versions of those problems, but to do that, you have to admit they exist. A person who says, "I don't have to worry about dynamic scope issues because my language is statically scoped, '(the dynamic scoping straw man (nobody forces it, and neither Haskell nor Scheme nor many others even support it!))'," is pretty much begging to discover -- the hard way -- that yes, Haskell and Scheme do give you the power to roll your own version of those problems by other means.

Most people don't realize how few concepts it takes to make a Turing-complete language, or how many different times and ways those concepts appear in a high-level programming language. They don't understand how things that look different -- like variable scoping strategy, closures, and currying -- can be different implementations of the same basic idea. Some, like the AM who made the original post in this thread, write the whole business off as, 'the "it's hidden but I'll look at it anyway," stuff'.

Those are the people who exaggerate and misrepresent FP, and there are a lot of them. Enough, in fact, that it's hard for someone trying to learn about FP to avoid them. They keep parroting the misinformation back and forth to each other and passing it on to the newcomers, who pick up the mistakes and the zeal based on the time they've spent in the echo chamber, instead of their own direct knowledge of programming.