well I upvoted you but I can't fully agree.
While you are write that a poorly-designed API that will make my code insecure is a bad design, however sometimes you just want the insecure design.
Something like making a insecure web service call to a legacy device that mishandles every secure request.
However I think it should at least than give a compiler warning/or a runtime warning.
Also changing a API of a stdlib is probably not a cool way. I like Java that they don't change things so fast, however in Java they rate of change is too slow, after deprecating something it should be removed some day (java never did), however in go/rust the rate of change is way too much. (and I really like rust) well both have a different release procedure than java, but still when I develop something I really hope that my API keeps the same at least 3 years or more.
Having a way to "break the seal" and void the warranty is fine, but it should require conscious decision making. Designing APIs such that the easiest, most straightforward use of the API voids any security guarantees just results in situations like the one that happened here, where everyone gets it wrong.
Also changing a API of a stdlib is probably not a cool way. I like Java that they don't change things so fast, however in Java they rate of change is too slow, after deprecating something it should be removed some day (java never did), however in go/rust the rate of change is way too much. (and I really like rust) well both have a different release procedure than java, but still when I develop something I really hope that my API keeps the same at least 3 years or more.