The motivation section and the entire text document are thin, because the whole problem is not a big deal.
Either the compiler allows to declare methods outside of the class definition, or not.
Was it done on purpose in the language? I'm not sure. It may just be something that the authors forgot to do.
I wanted to add my 5 cents, which is a small correction of the semantics of the language.
This fix is very useful and attractive because it makes it easier to separate the interface and the implementation.
I never said that this proposal is the only way to do that.
The proposal helps to simplify this separation, since the existing methods are either over-complicated or less effective.
I also addressed the concern of the declaration mismatch and wrote that it leads to the same error as in case of plain function - the linker error.
That is what I have.  Again, the whole issue is small and clear, and I cannot add anything more. 
If it is not acceptable, then I give up.
I agree with you that I failed to convince people. This is because of my insufficient experience and poor English.

I am ready to answer any relevant question, but I see I cannot make progress.
If someone wants to continue with it, then I really wish good luck, and I will support him.
I thank everybody who interested and participated.

чт, 26 авг. 2021 г. в 17:46, Thiago Macieira via Std-Proposals <>:
On Thursday, 26 August 2021 06:19:28 PDT Jason McKesson via Std-Proposals
> When Thiago asked you to write a proposal, I'm fairly sure he didn't
> mean for you to just take a couple of sentences from this thread and
> throw them into a text file. What we want is something more specific,
> more comprehensive as to the behavior of the feature, and which
> addresses the issues raised in this thread.

To be clear: I agree with Valery that there's a need. I've needed this before;
we use private implementation techniques all the time, with severe hacks to
reduce the number of memory allocations.

I'm not arguing to put a roadblock in the request.

I'm saying that the discussion on the mailing list will not lead to a fruitful
result. Someone needs to take the next step and write a very good paper. And
as any paper that addresses core language changes, it needs to provide
sufficient evidence for why this is a good idea, why the status quo needs to
change (like explaining what hoops developers need to go through), go through
the possible concerns the committee may have, explaining how they're
addressed, and in addition to the recommended syntax, provide alternatives
that were discarded.

I think the CWG has an incubator team that can help you write and improve on
the paper.
Thiago Macieira - thiago (AT) - thiago (AT)
   Software Architect - Intel DPG Cloud Engineering

Std-Proposals mailing list