It seems like every one of your examples is motivated by some form of
"default-init, assign later" pattern.

Personally, I see this as an anti-pattern. You should just initialize
things, not assign them. Later redeclaring it as const seems like a
bandaid solution to me. Every example could have also been resolved by
using the conditional operator, an IILE, or a do-expression (P2806R3).
I'm much more enthusiastic about the latter proposal because it can
eliminate the need to redeclare as const in the first place.

Furthermore, this feature is not free to use for the reader and writer
of the code. You need to be quite explicit here and I don't see people
being 100% consistent about redeclaring as const after initialization
takes place. This is similar to expecting everyone to remember to
free() after malloc(). The mental effort required to remember to
"const x" seems roughly the same as the effort required not to
mistakenly "x = ...", so what are you actually gaining here? The
reader also needs to keep track of where x is mutable and where it is
const; this is no longer readily apparent from the declaration alone.
So in terms of net benefit to developers, this may be
 zero or negative.

I don't think this is worth committee time, and it certainly would
require quite a bit of design discussion.