It would be cool to be able to just click on anything and adjust its code to however you like it. I guess that Smalltalk and its descendants allow this. But so does Emacs. It's not an operating system, but it covers a lot of the use-cases.
It's curious how the original 1981 paper [1] on TECO Emacs, written before I was born, describes many qualities I recognize in the ELisp Emacs I grew up on.
Emacs "happens" to be open source ;-), but the paper stresses how the system & language were designed to allow users to mold it at run time without the barrier of recompiling from source, and how empowering users led to better features than "careful design" could have achieved. Selected points I found notable:
- awareness that "An EMACS system actually implements two different languages, the editing language and the programming language".
- Editing Language is tweakable (again at run time) by re-binding keys to macros / existing commands / custom commands. This gives agency to users with less programming skill!
- Language separation being necessary so that tweaking Editing Language can't break Programming code.
- Key bindings are shallow "keyboard sugar" over the concepts of Programming Language. Commands are (almost) regular functions. User can invoke any command by name, bypassing the sugar.
- Buffer-local & mode-local bindings.
- Commands (and generally as much of the system as possible) implemented in Programming Language which was chosen to be interpreted not compiled, so that users can redefine at run-time and experiment.
- "The only way to implement an extensible system using an unsuitable language, is to write an interpreter for a suitable language and then use that one" :-D
- "variable [and function] names are retained at run time; they are not lost in compilation"
- Commands are extensively parametrized by variables. User can achieve quite a lot by simply setting [global] variables.
- Dynamic not lexical scoping deliberately choosen to make code less encapsulated and more reusable with tweaks. See paper why lexical is worse for dynamic
- Unique concept of File/buffer-local variables! Again, if programmer went to the trouble of parametrizing code, maximize the payoff.
- Commands and especially compiled code extensively parameterized by calling "Hooks" at interesting points. "These hooks can be thought of as compensating for the fact that some parts of the system are written in assembler language and cannot simply be redefined by the user." <<-- I found this especially thoughtful
- Social dynamics like "library system" for loading extensions written by others. Well, ater Emacs actually lagged behind for decades in ease of obtaining 3rd-party libraries. "too cathedral, not enough bazaar..." Much better now with MELPA, still not as smooth as say VSCode extensions. But I feel a trade-off — VSCode extensions are more "opaque".
To me Emacs fits the bill, or at least a subset thereof.