I again checked the sizes for lablgtk, but in this case they even seem to slightly decrease compared to 5.1.0.

@lthls As I commented in #10653, I beg to differ here.
The point is that if we follow the convention that any block of optional parameters must be followed by a non-optional one, without side-effects between them, then you wouldn't be able to see the difference. And n-ary abstractions make sure that the code computing the defaults is indeed not inserted between them.
I agree that all this should be properly written down, but I think the behavior here is correct, i.e. undistinguishable from #10653 for all useful purposes.

By the way, I just discovered something strange about n-ary functions.

let f ?(a=print_endline"a") ?(b=print_endline"b") = function c -> c

is a function of 3 arguments, and the defaults are computed after receiving c, but

let f ?(a=print_endline"a") ?(b=print_endline"b") = fun c -> c

is a function of two arguments returning a function, and the defaults are computed after receiving b. The difference seems strange to me. Is it really useful ?

This looks like the "syntactic arity" convention (https://github.com/ocaml/RFCs/blob/master/rfcs/n_ary_functions.md) that was recently implemented. Like all conventions, it can look strange sometimes, but I think that knowing (syntactically) how the compiler is going to handle a curried function definition is useful. I don't know if syntactic arity can help with the issue discussed here and in #10653, as I haven't been able to follow the discussion.

@lthls Thanks for the approval. I intend to add some comments explaining what this code does before merging (it took me a while to remember the details, as it was written 20 years ago). The behavior may be open to debate, but it is the intended one.

@xavierleroy Syntactic arity alone does not solve the problem, but if we combine it with the requirement that any n-ary abstraction must be terminated by a non-optional argument, which is the case in any reasonable code (except combinators used to build functions by combining sets of optional arguments), then there is no discrepancy with #10653, since side-effects are then guaranteed to only occur after a non-optional argument. That is why I suggested introducing a warning for that.
Note that the incriminating example in #10653 already disables another warning checking for the presence of a non-labeled parameter after optional ones, so it may not even be needed to add a new warning.