As Victor notes above, for systems where no suitable coercion target locale is available, even the "unsupported locale" warning is an issue, since it's only full Unicode text handling that's unsupported in such locales - you can still process ASCII-only and non-text data just fine in such environments (and even Unicode data if you're sufficiently careful).

As a matter of future-proofing CPython, we also need to account for the fact that some C implementations (potentially including future versions of glibc) may starting using UTF-8 as the default text encoding in the C locale itself (requiring the use of variants like C.ASCII or C.latin-1 to opt-in to the use of legacy text encodings).

I still think the warnings are potentially valuable for system integrators and operating system developers trying to ensure that C.UTF-8 is genuinely pervasive as their default locale, so my counter-proposal to Victor's PR is:

* remove the build-time warning flag
* gate the warnings for both successful and unsuccessful locale coercion behind a runtime check for PYTHONCOERCECLOCALE=warn

That means:

* we provide the best possible developer experience we can by default (i.e. no visible warnings, we assume UTF-8 where possible)
* redistributors have a relatively simple patch to always emit the warnings if they want to do so (i.e. remove the conditional checks)
* system integrators and folks debugging application misbehaviour can readily enable the warnings at runtime as part of fault investigation activities