The problem

Composing software statically has been solved for decades. Function calls, imports, inheritance: everything is decided before running and does not change.

Composing while it runs is another matter. And there, the paper says, the formal foundations are far less developed than the practical importance of the problem would justify.

There are two dimensions, and they are independent of each other.

• Temporal dimension Time When you remove a piece, everything it did has to be undone completely. Statically this is solved by variable scope.
• Spatial dimension Space Pieces have to be able to declare what they depend on and react when that changes. Statically this is solved by import resolution.

Statically both are easy. At runtime they get much harder.

The example everyone has suffered

The paper uses Visual Studio Code, and the data is specific. It was collected from the extension marketplace on 9 June 2026.

Data point	Figure	What it implies
Of the 100 most installed extensions	87	Contain executable code, and removing any of them forces a restart of the process hosting them all
Use the dependency mechanism	7	Of the same 100. The rest hook into fixed host points instead of depending on each other

There is a shutdown function, but it only runs when the whole process ends. And it is written far from where the thing it has to clean up was created, so verifying the cleanup is complete is hard.

When extensions do interact, what they receive arrives untyped.

The most lucid part

The paper asks why this has received so little formal attention, and gives a convincing answer: because a substitute already exists that works well enough.

• Substitute one The operating system Solves the temporal dimension at process granularity, which is to say by restarting
• Substitute two The orchestrator Solves the spatial one at service granularity

Both mechanisms operate at the process and container boundary. Modern software composes at a much finer grain. That mismatch is the gap the paper is trying to fill.