If you know someone who teaches or researches software design principles, I'd appreciate you sharing this — the argument needs to be challenged by people who take SOLID seriously.
The Interface Segregation Principle (ISP) is widely taught as the fourth independent letter in SOLID. I've written a short paper showing it isn't independent at all: it is a special case of DIP's ownership clause applied once per client–provider edge.
Once both principles are stated precisely enough to reason about formally, the argument is straightforward. DIP's ownership clause says the client defines the interface it depends upon. Apply that to one client: you get one client-specific interface. Apply it to a second client of the same provider: you get a second, different interface. The provider now implements both, each client sees only its own slice, and no client depends on methods it doesn't use — which is exactly what ISP prescribes. At the class level, the two principles produce the identical structure: the same classes, the same interfaces, the same dependency and implementation relationships.
The converse also holds: any ISP-compliant segregation is structurally indistinguishable from the result of applying DIP's ownership clause per client.
I'm not saying that naming ISP is useless — naming the corollary directs attention to the per-client application of DIP, which textbooks consistently underemphasize. The claim is narrower: ISP prescribes no design action that per-client DIP doesn't already prescribe.
The paper also examines why this connection went unnoticed for nearly thirty years. The most fundamental reason is that both principles were stated as informal design directives illustrated by examples, making logical derivation impossible until they are stated precisely. Other factors include DIP's single-client framing, ISP's status as the least-scrutinized SOLID principle, and the strong prior created by the five-letter acronym.
Building on observations by Henney, Oldwood, Kaminski, and North that SOLID's principles overlap, I traced a specific derivation that, to my knowledge, has not been identified before: DIP's ownership clause applied per client is ISP.
The full structural proof (at the class level), worked example, and historical analysis are freely available:
"The Interface Segregation Principle Is a Corollary of the Dependency Inversion Principle: A Structural Proof"
At the class level, is there a case where ISP prescribes a different structure than per-client DIP? If you think ISP adds something at other levels (packages, APIs, services), I'd be interested in that too — the paper's scope is class-level, and extensions are future work.