The author wanted to "generalize everything" and "wrap everything." And I can't imagine that he will ever use all the functionality that he tried to "cover."

Compare that to pragmatism of not spending time trying to do what's not going to be needed.

it is clearly a language related problem where the author shows that the language design is not consistent.

You can always work around these issues after all the language is turing complete.

However, this is not about if there is a program that functionally equivalent, this is about writing code that is minimal and can be read well and can be supported easily over a longer period of time.

What makes you say the language is not consistent? Default parameters are a feature of named functions. Currying is a different feature of functions. A curried function is equivalent to a non-curried function that returns a function. Since the returned function is not a named function, it cannot have default parameters. Therefore, default parameters are not allowed in curried functions.

Beyond that, the author's proposed API is most definitely not the best API design to use here, even if the default parameters did work in curried functions. A builder pattern would make a lot more sense. Or just do as Cocoa already does and provide a request object that can be customized before initiating the HTTP call.

If the goal is "is minimal " and "can be supported easily over a longer period of time" he should stick to the API and not try to wrap everything. He can make his own functions which are more minimal for his use cases. I argue that he will never in his code use most of the things he tries to cover. If he just writes just what he really needs in his real use cases he'll have much less problems for supporting it.

The worst code to support is "I don't use that but I might need it once."

The point is not the specific example, but that swift doesn't support currying with default arguments.