sorry for having written some imprecision in
https://lists.isocpp.org/std-discussion/current/3216.php

as I wrongly stated about the constness of unnamed data members,
instead of highlighting the constness of the function call operator
for the lambda closure type.

However, the question still remains.

The standard reads:
"
If m1 captures the entity by copy, m2 captures the corresponding non-static
data member of m1's closure type; if m1 is not mutable, the non-static data
member is considered to be const-qualified.
<https://eel.is/c++draft/expr.prim.lambda#capture-14.1.sentence-1>
"

which in final part seems wrong, because in case
of explicit object parameter the function call operator is also
stated to be not a const method, therefore I see a contradiction
by the text above: non-mutable but the explicit object parameter
makes the data members non const in the lambda body,
as done by gcc and clang in this example: https://godbolt.org/z/83vnEnMKx .
Also, sorry for the typo there, I wrote
"y = 3; of course, not allowed"
but it should have been
"x = 3; of course, not allowed"



Really, I do see another doubt now, and sorry
to mix two topics, but they appear quite overlapped.
The text of the standard in
[expr.prim.lambda.closure]-p7 reads
"
...
Otherwise, it is a non-static member function or member function template
that is declared const if and only if the
lambda-expression's parameter-declaration-clause is not
followed by mutable and the lambda-declarator does not
contain an explicit object parameter.
 ...
"
so, in case of explicit object parameter, we shouldn't be
able to invoke lambda on const closure objects, regardless
of the body changes or not any unnamed non-static data member,
isn't it ?
Here: https://godbolt.org/z/1x1PPE96v
I see gcc and clang doing some possibly-smart deduction on the
constness of the function call operator, mixing the nature of the
body and the deduced type for the explicit object parameter.
What was the real intent of the standard ? Should it really
be not possible to invoke function call operator on a constant
closure object ? This seems the obvious consequence of having
a non-const function call operator due to the explicit object parameter.
I only see it's fair for 'mutable', because this is a 'declaration of
intent'
by the programmer.