> Upon loading the executable, the representation of the object is also mapped into the process address space, so really no initialization happens at run time ...

So ... loading the executable and mapping the object representation of
the object happens at compile-time, not at run-time? This is obviously
false.

I get that it's cheap, and on modern architectures, doesn't require
any work to be done individually per object, but let's not get
sidetracked by implementation details. As described in
https://eel.is/c++draft/basic.start.static, all static initialization
strongly happens before dynamic initialization. However, it doesn't
happen "at compile-time". This would imply that the lifetime of the
object has begun before you have turned on your PC, let alone run the
program.

> A variable declared constexpr specifies to create a compile-time constant which can be used in other constant expressions.

No. It specifies that (https://eel.is/c++draft/dcl.constexpr#6)
> the full-expression of the initialization shall be a constant expression

In practice, this makes it feasible for implementations to evaluate
the initializer prior to program startup; however, this is not
required and wouldn't be implementable when writing a C++ interpreter.

> constinit has a different intention. It explicitly requires that initialization happens during compile time ...

While there is no such thing as "compile-time" in the standard, I
absolutely agree that the original intent of constinit doesn't make
much sense when applied to automatic storage duration variables. Their
lifetime begins when the function gets executed, so they cannot be
constant-initialized. However, I think it's reasonable to slightly
misuse the constinit keyword to equally imply that "the
full-expression of the initialization shall be a constant expression",
however, without also implying const.

I think my motivating example isn't too far-fetched and this feature
would be implementable, so it's quite reasonable to make a proposal.