I don't really see your point. Types can prove the absence of those bugs. "Writing good code" is not... anything.

Neither of the examples given need types if good interfaces to those functions are chosen. Since types are part of the interface then why wouldn't you just change the interface to not exhibit those bugs rather than using types to prop up a bad one?

How would an interface guarantee that close is not called twice, or that you have escaped a string exactly once?

I have rarely needed to escape a SQL string since the days of PHP4, nowadays it is standard to use parameter binding such as "SELECT * FROM table WHERE row = ?" - it's also faster since the query doesn't need to be recompiled every time, but if you really have a desire to escape SQL then you can write a string interpolation function that does it automatically e.g. sql_format("SELECT * FROM table WHERE foo = %s", s). Indeed, JavaScript supports this via custom templated string literals.

As for closing resources, you can use a pattern such as using(open("file.txt"), (f) => { ... }) if your language doesn't already support such a construct.

Escaping multiple times would be unnecessary with a type based system, by definition.

Sure, no one should need to do that anymore, it's just an example. There are many other cases that are similar, however.

`using` is a language construct, not something that is part of an interface. It also does not prevent close from being called twice.