And it seems like we still care about support Visual Studio 2017, even if Visual Studio 2019 and 2022 are available.
Can we make this more concrete? Do we know of affected parties? Numbers of affected users? Or are we just conservatively guesstimating the thickness of the long tail of support? On top of that, I think the formulation you chose does not map correctly to actual compiler capabilities. C99 (minus C11 optionals) only arrived in VS2019, there were still gaps in VS2017. I would advocate bumping the requirement to VS2019. Yes, there is a built-in reluctance to update toolchains, but MSFT has been _extremely_ conservative w.r.t. ABI-compatibility (e.g. the whole story with [[msvc::no_unique_address]]), and I just don't see the argument why a non-negligible portion of users cannot upgrade to the fully-compatible-with-everything-previously VS2019.
"Python 3.11 and newer versions use C99 in the public C API and use a subset of C11 in Python internals. The public C API should be compatible with C++. The C11 subset are features supported by GCC 8.5, clang 8.0, and MSVC of Visual Studio 2017."
If we were to require VS2019, then the formulation could be much nicer (IMO): """ Python 3.11 and newer versions use C99 in the public C API (without those features that became optional in C11), while Python internals may use C11 (again without optional features). The public C API should be compatible with C++. """