VC/VS 啥时候成标准了 ...
首先，C++ 编译器的前端是逻辑很复杂的东西（特别还有一堆扩展），在维护的时候出 bug 不小心 break 掉之前的代码挺正常的，一般针对 C++ 编译器，有很多公开的和内部的 test suite 来尽量使这种事情不会发生，但是这显然并不是一个完全的保证。任何 C++ 编译器出 bug 都是很正常的事情，另外我不知道楼主听没听说过 bug-to-bug compatible 这个东西 ...
从更广义的角度讲，任何对于开发平台和依赖的迁移都应该评估可能造成的影响，这和标准不标准无关，任何语言的任何版本的编译器 /库更新都可能引入新的 bug
注意 C++ 这个语言的模式是 WG21 定标准，不同的 vendor 做实现，Bjarne 原来的实现早就不知道扔哪去了。你在不同的实现之间迁移的时候也会遇到类似的问题，同时还会遇到 extension 不兼容的问题（还会遇到 ABI 的问题 ...），包括看上去是同一个 extension，不同的 compiler 会有不同的实现。
还有一种模式是没有 spec，实现就是 de facto standard。TypeScript 貌似是这样。OCaml 这种尽管是偏学术的语言，但是好像还是没有 spec，并且可以有 breaking change (
https://github.com/gasche/ocaml-releases-change-explanation/wiki/4.05.0-changes-explanation)，一个其他语言用户见不到的奇观是 check.ocamllabs.io ——为了官方发布新版本的升级过程更平滑，有人专门做了一个网站来监控所有包在新版编译器上的构建状况，因为社区小，所以这个事情可行。但是仔细看其中大多数都是第三方库等周边生态导致的问题，编译器本身还是尽量保持稳定的。Haskell 虽然有个标准当摆设，但是谁都看得出 GHC 是 de facto standard，所以同理 ...（典型：
https://gitlab.haskell.org/ghc/ghc/wikis/migration/7.10 ）。
LLVM 不算是用户直接接触的编译器，但是简单来说 LLVM IR 的兼容性就是随缘，尤其是对于非核心部分。OpenGL、OpenCL 和 SPIRV 等作为工业标准，标准是分版本发布的，各个 vendor 通过提 extension 的方式加私货，每个 extension 都有自己的 ID。实现上则用 版本号+extension 集合 的方式标识兼容性，Khronos 官方提供 Conformance Test Suite。我觉得这个做得是比 C++ 要更成熟一点的。
至于楼主的问题，我认为对于学生项目来讲，这个没有太大的问题。这里涉及到一个比较现实的问题是 MSVC 的编译器版本和开发环境版本是绑定的，你想用新的环境必须用新的编译器。这个不完全是个好事也不完全是个坏事。需要注意的是现在“开发环境和编译器版本绑定”已经是一个不限于微软的趋势了——越来越多的编程语言开始更多地在交互开发体验上发力，微软的 C# 本来做得就很优秀，但是后来通过开源的 Roslyn 更进了一步。C++ 社区则有 Clang 梦，不对，是 Clang 的伟大复兴，不对，应该叫 Clang 崛起 ... 总的来说是开发环境的工具越来越依赖于编译器自身的 API，这部分一般是没有兼容性保证的，并且挺容易 break 的。
一些优秀的 C++ 项目的编码规范里面规定的不仅仅有项目使用哪个 C++ ISO 标准开发，还有当前兼容的编译器**最小版本**，因为规定“使用 C++14 开发”之类的是没用的，你还得考虑编译器自身实现的问题
很多 C++ 项目本来就有跨平台的需求，这样所要面临的环境和工具链差异会更大，然而这些项目确实做到了。
你并不必需把你自己的项目也做成跨平台的，也并不必需使用标准 C++ 开发。但是我认为处理编译器和平台之间正常的兼容性问题是干活的程序员的必备能力之一，就像前端需要处理浏览器差异一样。
微软官方的解释：
https://docs.microsoft.com/en-us/cpp/porting/overview-of-potential-upgrade-issues-visual-cpp另外为什么没人黑一下 Python 呢？