Oh, you mean something like this?

    interface A<T> {
        T x();
        void y(T t);
    }

    void foo(List<A<?>> as) { // every element may have a different instance of T
        for (A<?> a : as)
            bar(a);
    }

    <T> void bar(A<T> a) {
        T t = a.x();
        a.y(t);
    }

There are no runtime type errors at all in TCL, either. That doesn't mean that the language is safer. "Safety" and "type safety" are not the same. Type safety has its virtues, but I would argue that Java's type safety is good enough; I would take it along with its dynamic capabilities over SML for many projects -- it's just a tradeoff that buys you a lot of other stuff. There's a price you pay for dynamic runtime capabilities and for deep cross-language interop (e.g. a Clojure list is a Java List), and that's a price worth paying in many cases, considering that it's not high at all.

> This is what happens when engineers design programming languages.

I guess engineers prioritize things based on what they're actually worth to developers (or, at least, according to how much they believe they're worth to their developers) as opposed to using an arbitrary metric for some intrinsic quality, whose relationship with actual benefit isn't at all clear. Java sacrifices a tiny bit of type safety for interop and various dynamic capabilities. I wasn't aware that there's been some major discovery showing that this is the wrong tradeoff to make.