I think your comment is analyzing the problem from a different abstraction level than the author's examples.

In other words, your alternative approach of "solving dependency conflicts" is abstract advice unless you try to make it concrete by focusing who solves those dependency conflicts.

Using the author's example of a VSCode conflict (collision of "/usr/bin/code") with Actor in italics:

- Microsoft owns commercial the build of /packages/visual-studio-code-bin

- Filipe Laíns & Massimiliano Torromeo owns the open-source-license build of /packages/community/x86_64/code/

- Levente Polyak, et al owns the Arch Linux distribution

- end user owns the computer that needs to run conflicting software

Generalize the above matrix to every software package and consider which of those 4 actors can practically solve the conflicts in a scalable way?

Filipe Laíns & Massimiliano Torromeo can't control what Microsoft does and vice-versa. (Ironically, the freedom to not be controlled by the other actor is one reason there's a package conflict!)

And Levente Polyak could "solve" it by blessing Filipe Laíns's package and rejecting Microsoft's but this creates a new "problem" for users who specifically want Microsoft's commercial build.

The fundamental issue is that you have independent actors that can't control what others do. Result is that sometimes software packages clash (namespace collisions, dependent libraries not in sync, incompatible licenses, etc).

The approach of using containers -- however flawed it is -- gets past the stalemate of independent actors in the software landscape being incompatible with each other.