It's a bit of a Turing tarpit when it comes to non-inherency.
1. PowerShell reimplements older commands as aliases, e.g. ls is an alias for Get-ChildItem. You'd not be relying on existing shell functionality.
2. I don't know much about it, but wouldn't the upcoming Linux IPC improvements being made to support kdbus do away with needing to handle message passing in the way you describe?
Perhaps my logic is off, or my view is missing key information, but from my novice perspective it seems to make sense.
If you're interested, this page has more information on the type system used in dbus: http://dbus.freedesktop.org/doc/dbus-specification.html#type...
Microsoft has been integrating interprocess communication into Windows since DDE in version 2.0 almost 30 years ago. Then more than a decade of OLE. Then more than a decade of .NET. At this point it and the reflection it enables are baked into the toolchain and pretty much comes along for free on a project. *nix has many advantages but everybody rowing in the same direction is not among them.
> PowerShell provides direct access to [nearly?] the entire Windows OS
PS has access to the .NET Framework which abstracts the OS APIs, not really to Windows directly.
There's also chatter that MS is already working on porting PowerShell to CoreCLR/.NET Core (the cross-plat, open-source version of .NET).