这是 C 的事情，发到 C++板块不怎么妥当吧

前半部分

1 ，这是 MSYS MinGW 的锅，它们没处理好 64 位的适配。Windows 提供了 fseeko64 的替代品 _fseeki64()，中间转换层本该做好映射支持的。
2~6 ，这就是系统 API / SDK 的锅，包括 Android

至于换语言能“解决”这些锅，本质上只是它们在标准库里面帮忙擦屁股而已。

「为什么开发环境就不能默认支持这些情况呢，难道还影响兼容性？」

开发环境当然可以默认支持这些情况，正常 POSIX 环境、正常 MSVC 环境直接写程序调用标准库 API 都没问题。
没做到默认支持，很多时候完全是疏忽 (MSYS MinGW)，或者是怕麻烦、赶进度(Android 5.0~6.0)。

后半部分

1 、若是 OS Level 的限制，编程语言本身能做的事情其实很有限。如果 OS 本身没解决 2038 问题，只要系统关机、重新开机，系统时间直接就是乱的，再完善的编程语言都没办法强行掰回来。
若 OS Level 已经解决了 2038 问题，那么无论是 C 还是 C++，都不需要担心这种事。

2 、纯 POSIX 可以。跨平台跨到 MSYS MinGW 的话，按理说 MSYS MinGW 应当处理好相应转换（像是背后处理编码调用带 W 的 API 、检测目标 Windows 有没有启用 UTF-8 区域选项），但这就不是普通使用者可以强制要求的了。

3 、这就有点霸道了，别说 C 语言、C++，哪怕是 Python 都没法如此保证。

4 、单纯“不拒绝使用”的话，那还是不需要担心。如果想要更高要求达到“表现一致”，那就不太可能了。
Linux 的 IPV6_V6ONLY 默认为 false ，而 BSD 和 macOS 还有 Windows 的 IPV6_V6ONLY 默认是 true 。
OpenBSD 更是搞起了内部限制，无论 IPV6_V6ONLY 设成什么值，它都按照 true 处理。

5 、类似 2

6 、支持近十年出厂的系统很合理。但硬件？？这可不是编程语言可以掌控的吧，这是 OS 和驱动程序的责任啊。