由于这个问题回到了四票结束，我再次尝试提出一个更狭窄的问题，希望社区会更积极地看待这个问题。
Java 中的哪些特定设计决策被记录为以它们的方式完成，不是因为这是首选的设计决策，而是因为有必要支持向后兼容性。
最明显的情况是泛型，您无法在运行时检测到类型参数。（所以你不能这样做：
public void addEmptyMember(List<?> someList) {
if (someList instanceof List<String>) {
((List<String>) someList).add("");
}
}
语言设计和标准 API 中还有哪些此类示例？
因为这个问题没有一个正确的答案，我不确定它是否会比你的其他问题更好。
我能想到的三个以向后兼容性为名做出妥协的特性（除了你已经提到的通用擦除）是新的 for 循环语法、可变参数和自动装箱。
新的 for 循环语法可能应该是 read for (item in List)，但这需要in变成一个保留字。这将导致许多向后兼容性问题，其中最重要的是System.in必须重新命名。
可变参数和自动装箱都增加了歧义的可能性。例如，如果您将一个对象数组传递给一个接受的方法，这Object...是否意味着该数组应该作为可变参数数组或可变参数数组的元素传递？如果有重载，这会变得更加复杂。自动装箱在重载方面也有类似的歧义问题。这两个问题的解决方案是制定一个规则，即在解决方法调用时，首先使用 1.5 之前的规则解决它们（即：没有自动装箱，并且Object...被视为Object[]）。只有当 1.5 之前的规则无法解决方法调用时，才会考虑新的 1.5 规则。
标准库中有很多例子
另一个是现在多个版本不推荐使用的所有类和方法，但不会消失。最值得注意的是已弃用的各种 Thread 方法。