It started with a series of tweets by C J Silverio:

@ceejbot: maybe this is the cold medicine, but was thinking that containerization is a reaction to a failure of operating systems. Well, unix.
@ceejbot: Or maybe it's a success, because you can do that on top of Unix, but at a cost.
@ceejbot: A app or server or "thing you want to deploy & run" can't be isolated. Config & deps are splattered all over.
@ceejbot: The container solves the problem of "isolate the consequences of installing & running this thing", which is what an OS should do.

My immediate reaction was that one big reason no OS has taken on actually doing this job is that doing it formally requires a huge formalized API.

Think of all of the abstracted things you may need to deploy an application. There's file storage, finding auxiliary files, hooking into (multiple) language environments, process startup and supervision, periodic task execution, logging, network ports, possible creation of separate limited privilege contexts, temporary scratch space, possible permanent writeable space, and so on and so forth. Today all of these are done in ad-hoc ways; you put magic files into magic places in the filesystem and things happen. To make them systematic, to make them formally part of what the OS does, you need to have a formal interface to do all of these things.

(I'm generously assuming that you're basically installing a service, instead of a command or a library or the like.)

There's a lot of things you can want to do for deployment on a general purpose OS. Really, a lot of things. An API that covered all of these things would thus be huge. Designing and building huge APIs is a big problem and they often don't work all that well.

(Regardless of what system they're in and what job they're trying to do. The stories of big APIs for anything are full of failures, perhaps because it's very hard for a coherent big API to emerge from existing practices.)

In this view, containerization is a move that's designed to reduce the size of the API by shifting complexity to inside it. Instead of being able to specify a complex, rich variety of things to do in deployment, you're restricted by the container API to a very small set of options. It's up to you to implement the remaining complexity (or at least its end result) inside the container, using whatever internal API for your own tooling or ad-hoc collection of hacks you like.

(Since currently most people base their containers on some existing Unix, they basically inherit much of the ad-hoc current ways.)

PS: the current ad-hoc magic file locations and so on are of course an implicit API, but from this perspective the two important things are that this implicit API isn't standardized across systems and it's not stable. It may or may not be documented particularly well or completely on any particular system.