I was thinking a lot about software malleability - but from a technical perspective.
I am on the verge of building something useful - only if I could find the time to do it.
Here's my premise - if you use something like a game engine, say Unity, and Unreal, you basically have the ability to modify everything in real time, and heve it reflected inside the editor immediately - you could change textures, models, audio, even shaders (which are a kind of code), and have the editor reload just that tiny resource instantaneously.
But not code code - for some reason computer code must go through a compilation, optimization and linking process, creating a monolithic executable piece of code, that cannot be directly modified. This is even true of dynamic languages like Js/Ts, which support modification on the fundamental level, yet somehow lose this ability when using advanced toolchains.
Which is weird since most compilers/OSes support this dynamism at a fundamental level - the machine interface unit of the C compiler is a function, the replacement unit in most OSes is a dynamic library, a collection of said functions - yet changing this at runtime is almost unheard of and most of the times suicidal.
This is because of a couple problems - memory allocation - replacing parts of a program at runtime can lead to leaks if we don't clean that up, resource allocation - this once again can be solved by tying resource lifetimes to either outside factors, or the lifetime of the function or its containing unit.
A demonstrated analog of this is OS processes, which can be terminated abruptly, their binaries replaced without fear of resource leakage.
The final problem of data corruption can be solved by making such program parts stateless, and making them use a store with atomic transactions.
I have a pretty good idea on how to build such an environment on the low level, whose core idea is having process-like isolation barriers isolating small pieces of programs, and an object database-like datastore that can never be corrupted due to transactional changes (which can be rolled back, enabling stuff like time-travel debugging). Said processes could communicate either via messages/events or sharing parts of their memory.
Such a system would allow you to fearlessly change any part of the source code of a running application at runtime - even if you mess up the code of a said component - say event to a point that it doesn't compile - all that would happen would that single component would cease to function without affecting the rest of the app.