[expr.prim.lambda.closure] Ambiguous parsing of implementation freedom

The second sentence in paragraph 3 reads:

An implementation may define the closure type differently from what is described below provided this does not alter the observable behavior of the program other than by changing:

• the size and/or alignment of the closure type,
• whether the closure type is trivially copyable ([class.prop]), or
• whether the closure type is a standard-layout class ([class.prop]).

I think the intent of this sentence is: "the implementation isn't allowed to alter any observable behavior other than by changing these things" (i.e. the implementation can't change anything other than the size, alignment, etc.) But it really strongly reads to me that "the implementation may define the closer type differently [...] other than by changing" (i.e. the implementation can change anything except for the size, alignment, etc.) Which is the exact opposite of what I think the intended meaning is.

If we worded it this way instead, I think it would be impossible to misread:

An implementation may define the closure type differently from what is described below provided this does not alter the observable behavior of the program, except that an implementation may alter:

Start with paragraph 3 of [expr.prim.lambda.closure] in the C++ draft and compare the current sentence with the wording proposed in this issue. Done means the sentence unambiguously permits changes only to the listed closure-type properties while preserving other observable behavior.