Thinking on it further, I'm going to try w/o the debug libraries, even if that disables some things,
(I'm not developing for Windows myself, so take everything I say with a grain of salt).
I think in general this may not be as large of an issue as it may seem at first, since usually you would test your C++ libraries with a C++ testing framework first (which supports msvcrtd). I'm not sure if the debug version of msvcrt provides any major benefit for the rust code itself, so if you are reasonably confident in the quality of your C++ library, then I think it may only be a minor inconvenience
If nobody on the steering committee (or whatever) recognizes this as a major problem
There is not really a steering committee in that sense. However, Microsoft is actually a foundation member and does also contribute to the Rust eco-system. If it was a major issue, I would expect some Microsoft engineers to already have driven a fix forward.
Yes I see the way the wind is blowing with regards to development (VS Code over VS), but something tells me that even if the dev environment goes away in favor of CMake
FYI, we are currently talking about the MSVC ABI. Which IDE you use is kind of orthogonal (except that VS probably only supports compiling for the MSVC ABI). CMake by the way also supports:
a) Using Visual Studio as a Code Generator (targetting MSVC ABI)
b) Using Ninja as a Code Generator in combination with clang to target the MSVC ABI (and be MSVC commandline compatible).
Just in case you are interested, I'm maintaining a CMake integration for cargo called Corrosion and I wrote some documentation on this issue and how to solve it in CMake.
Basically in CMake you can do set_target_properties(your_cpp_library_target PROPERTIES MSVC_RUNTIME_LIBRARY "MultiThreadedDLL").