Unpopular take but here I go (bye bye karma): Code sharing between applications, beyond what is basic, common and stable enough that it could live in the kernel, is not a good idea in the long run. It served a purpose back when memory was scarce and libraries (and their versions) few.
Containerization for all it's isolation magic has primarily been successful as a way to package "more or less the entire OS dependency" because sharing code is hard. How many containers ship with only one single binary (the active data set) ? None, code sharing is the primary problem that containers solve.
Static linking solves it better. RiscOS approach actually solves it better, too.
Code sharing should not be done, because it is a hard problem?
Stuffing whole OSes + apps + their dependencies in containers, and running a # of those, is not the solution. That works for single-purpose uses like servers. Not for user-facing OSes that run a # of apps side-by-side.
Solving that "how to share code reliably" problem is the solution. Being a hard problem means it's worthwhile to find a good solution for it.
Sharing code runtime is not a hard problem, it's the wrong problem. Code _sharing_ shouldn't be done. Code _reuse_ sure, absolutely, and it's done right by including that exact, specific code at compile time.
And yes, stuffing whole OSes + apps + deps into containers is indeed not the solution, it's the symptom.
Containerization for all it's isolation magic has primarily been successful as a way to package "more or less the entire OS dependency" because sharing code is hard. How many containers ship with only one single binary (the active data set) ? None, code sharing is the primary problem that containers solve.
Static linking solves it better. RiscOS approach actually solves it better, too.