One of the big challenges of "Doing better" is presenting data in a way that makes sense. IBM kinda tried to do it with OS/2, which used document object model (DOM) and the various objects in your GUI were actual objects that you could drag and drop and would interact with each other. I saw a couple of attempts by various developers to make use of that, but they never really worked that well and the idea kind of fizzled out. Gnome also tried to do it and I guess technically dbus does kind of try to implement it, but the only time I ever notice dbus is when it's making my emacs windows hang on startup (Which hasn't happened in a while, so they either fixed that or I'm not trying to use emacs in a way that causes the problem anymore.) Funnily, IBM, which put a lot of cutting edge stuff in OS/2, never really used any of those features in their own applications. A big portion of the company viewed OS/2 and intel processors as toys that would never multi-task as well as the mainframes do. Also funnily my phone now multitasks better than their mainframes did at the time, so suck it 1995! HAH!

But I digress. The closest I've come, personally, to "doing better" as you suggest in your article, was by implementing Python APIs to heavily-threaded C++ objects using Pybind11 and starting C++ threads in the same memory space from a Python interpreter process. The C++ threads would happily run in the background, unaffected by Python's global interpreter lock, and I could post requests for work to a queue in Python and the C++ code would pick it up and run it behind the scenes, making the results available in another queue for me when the tasks were completed. I think if I wrote some Imgui objects with that functionality, I could launch multiple graphical controls from the Python process. Some of the C++ objects I wrote could run rest services as well, and it was kind of neat to post something to a rest service in one window and see an array in Python get updated in real time.

Outside of that, there haven't really been any major advances in shells that I'm aware of since before threads made it into Linux, and that's really a shame. Changing environment variables in threaded programs is a pretty good way to crash your program and it would require some fundamental changes to the process model and C standard library to fix that. Easier to just implement your own thread-safe data store and stop using environment variables.

I'm not sure there's a great way to represent an execution graph that would mimic the simplicity of pipes in a text mode environment. It'd probably morph into a model where you start multiple agents to monitor things and they'd be capable of notifying you with graphical controls or pop-ups when something they were interested in happened. The down side of that model is that if one thing crashes in your thread space, the whole thing crashes (The Windows 3.1 problem.) So applications written to exist in such an environment would have to be a lot more careful about things like null pointer dereferences and array bounds overflows and all those fun things.

I think about this every few years and ponder trying to experiment with writing a shell and environment like that, but bash in a process with UNIX pipes really works well enough for me. Anything more complex and I reach for a programming language. Python might end up being my shell at some point, if I keep writing objects that it can interact with in C++ or other languages. Rust has a library similar to Pybind11, too, so maybe that will end up being the thing that finally bridges all the gaps and allows multiple languages to be used to develop applications that can actually work together (Kinda like Corba, DOM, COM/DCOM, RPC and REST were supposed to heh.)