I’m an outsider to os Dev and have never read posix standards or similar but I’m curious if an entirely different operating system would achieve benefits worth the cost of incompatibility. Things like the concept of treating everything as a binary stream (shell output, data transfers etc) seem like a design choice with roots in early computing which doesn’t lend well to complex and secure systems.

An example is that if we move to shells where everything is an object with a toString method for stdout, we would avoid many bash bugs in piped commands or shell scripts. I’m sure many concepts such as file io etc could achieve different but worthwhile benefits if reengineered from a modern perspective, even tcp/ip has its warts (but I’ll acknowledge we will never get away from tcp/ ip).

Am I just a clueless outsider?

I’m also not an OS dev. However, sometimes while cutting, pasting, and grepping my program outputs I’m vaguely jealous of powershell I think they use some sort of objects over there…

You can install PowerShell on Linux now, if you like - or there's nushell: https://www.nushell.sh/

Two big differences between PowerShell (even on Linux) and traditional Unix shells: (1) multithreaded single process architecture, as opposed to multi-process architecture; (2) runs under a VM (.Net CLR) as opposed to native code.

I see nushell is written in Rust, so it doesn't have (2), although I'm less sure about (1).

I think it would be cool if you could add structured pipeline support to traditional Unix tools (bash, coreutils, etc). The problem is, Unix pipes don't have any support for passing metadata (performing content negotiation between the two ends of the pipe). Given they are a facility provided by the kernel, adding that would likely require kernel changes.

One day I started daydreaming about prototyping content negotiation support for Unix pipes. I was thinking of using CUSE (Linux character device driver in userspace) to do it. Never actually got around to trying though, other more pressing things to work on. Maybe some day I will get around with it, or maybe someone else will feel more enthusiastic about that than I do.

The way it works is it uses fd3 to communicate schema information so it can natively support all the existing "dumb" pipes without any modification but any new tools can be written to send objects instead (albeit byte encoded).

It's not as elegant as PowerShell sending .NET objects natively, but then PowerShell doesn't work with existing CLI tools natively (it needs wrapper scripts to convert them into PowerShell commands). Whereas my shell is fully backwards compatible while still supporting a suite of additional functionality too.