This change in particular seems to be removing an imperfect attempt to specify something which is not easily deducible from other normative wording.

This says that whether the constructor is a constant expression relies only on initialisation of that one alternative, and nothing else. The equivalent wording for duration and pair and tuple does the same, but it's arguably easier to deduce that from the exposition-only members of those types. Here I think we're actually losing useful wording.

Maybe the correct fix is to say an evaluation of this constructor is a constant expression if...

But just removing these words doesn't seem like an improvement to me. Until we resolve the much larger "what does the library mean when it says something is a constexpr function" issue this wording is not redundant and is load-bearing.

Do you really need to say that? This what you are saying is conditional constexpr, but now constexpr is just an opt-in to constant-evaluation, it's not guarantee, you can just "this function is marked constexpr", and if any of the subtype constructors is not, it will fail to call it.

Why do you need specify conditional constexpr only for these types (pair/tuple/time_duration) it feels like a redundancy and language wording is enough. Especially with templates you must explicitly aim it on make something constexpr not evaluatable.

The conditional constexpr described in these Remarks would currently always be present, and it's an improvement of the status quo to make it unconditionally constexpr. The issue described is likely broad enough to warrant a paper, so it seems a bit silly to hold back this correct editorial change.

What seems to be missing here is a Constant When specification, but that would require non-editorial changes. It also seems to me that there's a much broader issue of under-specifying in the standard library when calls to constexpr functions are constant expressions and not. For example, we don't say anywhere in [algorithms] that running constexpr algorithms is a constant expression only if every operation performed on the iterators is a constant expression, do we? Should that be specified for each algorithm or as blanket wording? Big questions ...

Can't we just address that as blanket wording in [library] anyway?

For this particular paragraph, it is stated that the variant value-initializes the first alternative, so it seems clear enough that it wouldn't produce a constant expression if that value-initialization isn't a constant expression.

That doesn't guarantee that the constexprness relies only on the constexprness of that initialization, but the same applies to basically anything that's not specified as "Effects Equivalent to:" We never say that std::countl_zero doesn't use goto internally, and yet it's marked constexpr, and yet it always produces a constant expression in practice.

If that is okay, then we shouldn't need to point out when exactly std::variant initialization is a constant expression either, since we do that basically nowhere in the standard library and it seems like a big effort to attempt consistency.