It really depends on your definition of static typing. The thing that always made implicit nullability such a mess is precisely that it breaks the subtype relat

It really depends on your definition of static typing. The thing that always made implicit nullability such a mess is precisely that it breaks the subtype relationship - that is, given some (reference) type Foo, you can have a null value of that, but none of the operations that normally apply to Foo apply to that null Foo value! In other words, it's not actually of type Foo, at least not under any sane definition of what a "type" is. So it was always a hole in static typing, and experience with all the grief caused by this hole is why we're moving away from it now, and why even the person who originally introduced this approach in the first place believes it was a mistake. But, yes, using dynamic typing would be even more irresponsible than using implicit nulls. And this is also something we've learned from experience - note how historically dynamically typed languages are acquiring some form of bolt-on statically checked typing (TypeScript, Python type annotations etc), and how quickly this is becoming the preferred way to write new code.