If these "native commands" had a sensible output format, integrating them with powershell would be as simple as putting ConvertFrom-Json or ConvertFrom-Csv in the middle of the pipeline. And let's be real, it's as poorly "integrated" with "native commands" as bash or zsh is poorly integrated with native commands.
You're not wrong, but the fix is then, "hey, let's extend the functionality of literally every *nix command". Which is hard to achieve. Building sensible serialized object-oriented output is the same problem as building sensible object-oriented output. That's why jc exists, I suppose.
There is always ConvertFrom-String. The problem is that it is one of the least intuitive and worst-performing commands I've used in Powershell. It's awful and I hate it. It's like writing sed and awk commands without the benefit of sed and awk's maturity and ubiquity. IMX, only Compare-Object has been worse.
It sounds like there needs to be a monolithic solution built from the ground up for interoperation.
Updating coreutils is a losing game at this point. Of course people will get angry when a well designed solution gradually takes over simply, because it is better.
What would I use PowerShell to do, though? Most of Windows is a GUI.
That's a key problem with the developer story on Windows, especially coming from GNU/Linux. Where are my standard compilers and libraries? What use do I have for a terminal on Windows? In bash, I get powerful commands and a simple text-based pipeline hooked up to coreutils and literally anything else that runs on the command line, which is a metric ton of software in that ecosystem.
Back to Windows. What would I want PowerShell to do? What would I use PowerShell for that I wouldn't want to just use Bash instead? Windows doesn't have coreutils or nice command line software to do fun or powerful things with.
I see PowerShell as a "look we have a terminal!" from Windows, but nothing that I want to do in said terminal to motivate me to learn.
Eh, not really. Powershell itself is fairly limited in terms of functionality. It's basically one step removed from a .Net REPL, and the .Net classes aren't necessarily written to do *nix admin tasks. It gives you all of .Net to build tools with, but sometimes you still run into Microsoftisms that are total nonsense. There's a reason every C# project was using Newtonsoft's JSON.Net instead of the wonky custom data representations that MS was trying to push left over from the embrace/extend/extinguish era.
If you think .Net is the best way to interact with a *nix environment for administration, by all means go ahead. I think you'll have a lot of fun discovering the problems with it. Lie most tasks involve a pipeline of native commands. Well, if you want a Powershell command in the middle, that means you have to run a native command, marshall the output to an object, do the Powershell commands, then serialize that output back into characters, and then output to a native command. And you potentially have to deal with Powershell thinking in UTF-16 and *nix thinking in UTF-8.
However this is social media, not an academic paper, and you didn't put much effort into backing your claims, either.
