Example in which evaluation limits determine overload resolution:

constexpr int f(int max) {
	for (int n = 0; n != max; ++n) {
	}
	return 0;
}

int const x = f(1048572);
int const y = f(1048573);

template<int = x>
constexpr bool f() {
	return true;
}

template<int = y> requires true
constexpr bool f() {
	return false;
}

static_assert(f());

https://godbolt.org/z/vzf847MYc

Same example without needed global constant int:

constexpr int f(int max) {
	for (int n = 0; n != max; ++n) {
	}
	return 0;
}

template<int = f(1048572)>
constexpr bool g() {
	return true;
}

template<int = f(1048573)> requires true
constexpr bool g() {
	return false;
}

static_assert(g());

See it live: https://godbolt.org/z/441PzG517

EWG discussed CWG2776 during the Tuesday Morning session in Kona. The following polls were taken.

CWG2776 "Substitution failure and implementation limits" we would like to resolve this issue by making it ill-formed to hit an implementation limit (such as constexpr evaluation) and later using this 'failed constexpr" value (or a derived value) in a context where constexpr is required. A paper is required.

Result: Not Consensus

CWG2776 "Substitution failure and implementation limits" we would like to see a paper which makes this either IF-NDR, or well-formed.

Result: Consensus

EWG St. Louis: @cor3ntin volunteered to write a paper