Proposed resolution:

This wording is relative to N5032.

[Drafting Note: Two mutually exclusive options are prepared, depicted below by Option A and Option B, respectively.]

Option A: Requiring usability in constant expressions.

1. Modify Table [tab:time.clock] — Cpp17Clock requirements as indicated:

   Table 131 — Cpp17Clock requirements [tab:time.clock]

   Expression	Return type	Operational semantics
   […]
   C1::is_steady	const bool	`true` if t1 <= t2 is always `true` and the time between clock ticks is constant, otherwise `false`. `C1::is_steady` shall be usable in constant expressions ([expr.const]).
   […]

Option B: Allowing varying between executions.

1. Modify Table [tab:time.clock] — Cpp17Clock requirements as indicated:

   Table 131 — Cpp17Clock requirements [tab:time.clock]

   Expression	Return type	Operational semantics
   […]
   C1::is_steady	const bool	`true` if t1 <= t2 is always `true` and the time between clock ticks is constant for the duration of the current program execution, otherwise `false`. [Note ?: `C1::is_steady` is not required to be usable in constant expressions ([expr.const]) and can vary between different executions. — end note]
   […]

In [time.clock.req]/[tab:time.clock], the static data member `C1::is_steady` seemingly indicates the property of the clock statically, as the requirements say "always".

However, it is not clear whether `C1::steady` should be usable in a constant expression. A hostile reading may indicate that it is allowed to make `C1::steady` only defined in some separated translated unit and/or initialized from some non-constant expression.

Also, it is not very clear that the "always" means the conditions always hold in all executions, or only always hold in the current execution. The latter reading allows `C1::steady` to vary between executions.