What I meant by this is that the newline character is the primary delimiter of the data, but I take your point. IMO, the best way to tackle the myriad ways of structuring data is to write parsers for them, not to rewrite the programs themselves to work with your shell's idea of structured data. That's a losing battle.
Interesting note: newlines are perfectly valid characters in file names. In fact, the only byte that cannot be in a file name is '/'[0], which means that you're asking for trouble trying to parse the in-band signaling you have to do with a stream that's pretending to be structured.
[0] with a hex editor it is possible to create a file system entry using '/' in its name. Linux does not handle this situation with grace.
This is how I felt powershell ought to go on Linux - parsers from every config format to a common intermediate and back, argument completers for every common shell command to a standard intermediate representation.
I think that’s a losing battle as well due to the brittle nature, any tweak to any command output could break something, meaning endless maintenance work on a large scale.
Rewriting concepts into new commands at least bring consistency and a chance of shrinking maintenance work as it settles on a nice design - and if not the maintenance won’t be endless rebuilds of the same parsers.
What I meant by this is that the newline character is the primary delimiter of the data, but I take your point. IMO, the best way to tackle the myriad ways of structuring data is to write parsers for them, not to rewrite the programs themselves to work with your shell's idea of structured data. That's a losing battle.