I don't see any convincing motivation for this proposal. As Jason has
pointed out, there is typically little to no difference between the
default constructor and the "moved-from constructor". We should also
generally standardize existing practice, and this proposal provides
zero examples of this pattern being used in the industry; it's a "hey,
wouldn't it be cool if we all started doing this?" proposal.

Also to point out the obvious, "initialize and assign later" is an
anti-pattern, and there is consensus on that. For example, see
https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Res-init
"ES.22: Don’t declare a variable until you have a value to initialize
it with". Your first example could have been written like:

> BigExpensiveType obj = [] {
> // complicated initialization stuff ...
> return get_actual_value();
> }();

A genuine problem with such IILEs though is the lack of mandatory
NRVO, which becomes relevant when we don't just produce a prvalue from
the lambda. Mandatory NRVO is genuinely worth solving.

After reading through your messages and your proposal, I cannot find a
proper motivating example. You have a default constructor like:

> LargeBuffer() : data(nullptr), size(0) { /* Potentially expensive setup */ }

Conveniently, this sweeps the motivation under the rug and just says
"potentially expensive setup". Why would the default constructor need
to do a more expensive setup than the moved_from static member
function? Also, why would that setup be wasted by subsequent
modification? Your populate() function is poorly written because it
discards the allocation that the current object may already have, but
this is not generally necessary. If the default constructor did
"potentially expensive setup", there's no obvious reason why
populate() couldn't make use of that expensive setup.

The fact that it's so hard to come up with a shred of motivation for
this proposal shows that it's a waste of time.