std::is_constant_evaluated behavior
if constexpr requires a constant expression for a condition. So is_constant_evaluated is of course always going to be true in such a context.
It's meant for a regular if. The purpose is to not go into a code path that is illegal in a constexpr function when evaluated in a constant expression. But to let it execute in runtime. It's not there to eliminate those code paths from the function altogether.
Here's how I think about this, maybe you'll find this helpful... maybe not. Note that I think writing if constexpr (std::is_constant_evaluated()) will be a really common error, and it's an easy trap to fall into. But hopefully compilers will just diagnose that case. Submitted 91428, which is fixed for gcc 10.1.
We essentially have two different rules for code - the typical rules for normal runtime code, and the restrictions for constant expressions that are for constexpr programming. Those are the expr.const restrictions: no UB, no reinterpret_cast, etc. Those restrictions keep decreasing from language standard to language standard, which is great.
Basically, control flow (from a code path perspective) alternates between being in the "full runtime" mode and the constexpr mode. Once we enter the constexpr mode (whether by initializing a constexpr object or evaluating a template parameter or ...), we stay there until we're done... and then we're back to full runtime mode.
What is_constant_evaluated() does is simply: Am I in constexpr mode? It tells you if you're on a context that requires constant expressions.
In that view, let's look at if constexpr (is_constant_evaluated()). Regardless of what state we used to be in, if constexpr requires a constant expression as its initialized so this lifts us into constexpr mode if we weren't there already. Hence, is_constant_evaluated() is just true - unconditionally.
However, for if (is_constant_evaluated()), a simple if doesn't change our state between runtime and constexpr. So the value here depends on the context it was called from. Initializing test4 puts us onto constexpr mode because it's a constexpr object. For the duration of its initialization, we follow the constant expression rules... so is_constant_evaluated()is true. But once we're done, we're back to runtime rules... so in the initialization of test5, is_constant_evaluated() is false. (And then test6 is an unfortunate language special case - you can use constant integral variables as constant expressions, so we treat their initialization the same way for these purposes.)