Malleable software: Restoring user agency in a world of locked-down apps

Still working on the UX a little but it seems close to what you want (and I agree). The vision statement is about creating immortal software exactly to fight bitrot https://github.com/tomlarkworthy/lopecode

I've been to hotel rooms that looked identical to each other. I've never been to anybody's long-term home that wasn't unique—and unique in obvious, personalized ways. Even the most regularized housing ends up unique: I've visited everything from US dorm rooms to ex-Soviet housing blocks to cookie-cutter HOA-invested suburbs and yet, rules and norms aside, folks' private spaces were always unique, adapted through both conscious action and by unconscious day-to-day habits.

Just because 90% of these modifications did not need more DIY tools than the occasional hammer and nail does not mean they don't "count". That just shows that reducing friction, risk and skill requirements matters.

Gentle ramping helps in two ways. For people who would be inclined to get into more "advanced" modifications, it lowers the activation energy needed and makes it easier to learn the necessary skills. But even for people who would not be inclined to go "all the way", it still helps them make more involved modifications than they would otherwise. A system with natural affordances to adaptation lets people make the changes they want with less thought and attention than they would otherwise need—the design of the system itself takes on some of the cognitive load for them.

With physical objects like home furniture, the affordances stem from the physical nature of the item and the environment. With software, the affordances—or lack thereof—stem entirely from the software's design.

Mainstream software systems are clearly not designed to be adaptable, but we should not take this as a signal about human nature. Large, quasi-monopolistic companies are driven by scalability, legibility and control far more than user empowerment or adaptability. And most people get stuck with these systems less because they prefer the design and more because there are structural and legal obstacles to switching. The obstacles are surmountable—you can absolutely use a customizing Linux desktop day-to-day, I do!—but they add real friction. And, as we repeatedly see through both research and observation, friction makes a big difference to most people. Friction has an outsize impact not because of people's immutable preferences but, as you said, because people have finite pools of time and attention with too many demands to do everything.

pike/roxen had a brief window of growth in the 90s but the leaders at the roxen company (not the devs) missed the opportunity to work with the FOSS community.

pike is fully C-syntax, and it is very performant, so that may be interesting for you.

societyserver is my fork/continuation of a university project called open-sTeam that stopped development more than a decade ago. i continue to use it and when i am not busy earning money try to work on it, but i haven't yet been able to build a community around it.

the process isolation you talk about sounds like something that erlang promises as well, but i don't know enough about erlang to tell. i'd be curious to learn more though.

open-sTeam/societyserver built an object-level access control system. method calls on others object are being intercepted and only allowed to pass if the caller has the necessary permission to access that object.

it's not process isolation, but also a concept i find interesting

The gaming audience is probably the most demanding of any regarding customization, modding, accessibility and other similar principles -- when the market forces line up and they are flush enough to offer more malleability video games frequently do.