Yes! This reminds me strongly of the core/modules architecture of the apache httpd, as described by the excellent O'Reilly book on it.

The process of serving an HTTP request is broken into a large number of fine grained stages and plugin modules may hook into any or all of these to modify the input and output to each stage.

The same basic idea makes it easy to turn any application concept into a modules-and-core architecture. From the day I read (skimmed) that book a decade or two ago this pattern has been burned into my brain

ECS systems for the gaming world are somewhat like this. There is the core ECS framework and then the systems and entity's integrate with each other

ECS is incredible. Other areas should take notice

Agreed. I find that we're going in this direction in many areas, games just got there much faster.

Pretty much everywhere there is some undercurrent of "use this ultra-small generic interface for everything and life will be easier". With games and ECS, microkernels and IPC-for-everything, with frontend frameworks and components that only communicate between themselves via props and events, with event sourcing and CQRS backends, Actors in Erlang, with microservices only communicating via the network to enforce encapsulation... Perhaps even Haskell's functional-core-imperative-shell could count as that?

I feel like OOP _tried_ to get to this point, with dependency injection and interface segregation, but didn't quite get there due to bad ergonomics, verbosity and because it was still too easy to break the rules. But it was definitely an attempt at improving things.

ECS?

Entity-component-system paradigm. Compared to OOP, ECS is more "data-first". It's like a database of components (attributes such as Position, Velocity, Player) with entities (simple integer identifiers) as keys. Systems are functions that query for components and perform actions on them. See Shipyard, enTT, Bevy, flecs, etc. The design space is still evolving.

As a database guy I really can get around this. OOP hurts my head sometimes when the hierarchies get too deep.

COM, OSGI, Service architecture, microservice architecture and countless other approaches. This is correct way to build applications, because it gets reinvented over and over again.

That’s pretty much what Erlang/OTP is, and it’s like a whole OS. Though it lacks capabilities.