Any developer working on cross-platform projects has noticed that code compiled using Visual C++ compiler (cl.exe) performs poorly compared to same code compiled using gcc on Linux or even MinGW or Cygwin, or clang, either stock or clangCL.
The basic reason is that in the early days, Microsoft didn't try to follow any standards and wrote everything from scratch. This meant that most of the time they spent writing something new instead of trying to test the old to make sure it works correctly and optimally.
When a program crashed due to issue in it or libraries it used, a memory dump was sent for Microsoft for analysis. If similar memory dump was sent by enough people, the issue was elevated to higher priority. If fixing the issue took more than 2 years, it was discarded as new compiler version was already release to public.
Because Microsoft didn't follow what other compiler projects decided, a lot of code had to be specifically adapted for Visual C, so it would compile, even if for example both gcc and clang could compile the code without changes. Recently Microsoft started phasing out their own C compiler and using clang as basis for a new compiler that would be backwards compatible with their own compiler. This caused issues when the internals differed too much and Microsoft's resource compiler couldn't handle Windows headers adapted for clang.
During last year, Microsoft started adding more and more open-source projects to their internal testing process to verify their compiler can compile open-source projects with minimal number of compiler-specific changes. Even then, some breaking changes were already scheduled and relayed to those open-source projects for implementing workaround.
Developers can send code to Visual Studio team to analyze if they think that the one of the compilers generates bad or suboptimal code. If the team thinks that enough people would benefit for better code generation or optimization, the team will queue a fix for a future release.
Sometimes the users suggest new platforms or processors that Visual C++ compilers should handle correctly. All supported platforms use unified headers, which select supported features by set of processors. Sometimes this set is not correct or complete and cause compilation to fail. Sometimes Microsoft use their own header names to separate processor architectures when more than one architecture use same name for architecture-specific header, even if most of the function prototypes are identical and the only difference is the number of supported functions. They assume people use Microsoft-specific architecture-agnostic header instead.