I don't think you need to get very complex to design a language that protects libraries from having implicit system access. If the only place that can import system APIs is in the entry program, then by design libraries need to use dependency injection to facilitate explicit passing of capabilities.
One can take just about any existing language and add this constraint, the problem however is it would break the existing ecosystem of libraries.
Yes, there is a sense in which Haskell's "effect systems" are "capability systems". My effect system, Bluefin, models capabilities as values that you explicitly pass around. You can't do I/O unless you have the "IOE" capability, for example.
One can take just about any existing language and add this constraint, the problem however is it would break the existing ecosystem of libraries.