> No it does not "must know the value". It would only "know the value"

You're right, that's a better way of wording it.
A stupid compiler might discard the information.

> This proposal really feels like it wants to just be conditionally
> constexpr parameters. Or just being able to overload on a parameter
> being a constant expression (which is really the goal here).

That's not what the proposal is about, and that's not the goal. If you
look at the motivation examples, overloading for constant expressions
wouldn't solve them nicely.

First of all, this should ultimately not produce any additional code.
Constexpr parameters would require a separate function, so by their
very nature, they increase code size since multiple functions are
created.

Secondly, things become really awkward when one wants to combine
constexpr parameters with runtime parameters. For instance, the
example with `rotate` might benefit even if just one or two of the
given iterators have a known value. A GCD algorithm might benefit if
only one of the two operands are known. Covering all possible
combinations with constexpr/runtime parameters leads to exponential
function signatures, and instantiations, and this is not nice.

Furthermore, a statement such as
> if provable (end - begin)
might never produce a constant expression, especially if the operator-
isn't marked constexpr.
However, it is still possible to know the distance between them.

A similar case is
> void foo(int x) {
> if provable (x <= 16)
It is possible that the compiler knows that x has a really small
value, without x actually being a constant expression. Perhaps it
knows that because x is a literal at the call site. Perhaps it knows
that because x is the result of a division with a large divisor.

I could list more examples, but it should be obvious at this point
that this feature is NOT constexpr parameters. It is tremendously more
powerful in some areas, and much less powerful in others.