The M x N interoperability problem is SOLVED BY building on top of bytes /
plain text, not solved by moving AWAY from it!
I never argued that we should move away from plain text. Indeed, one of the examples I cited of an interoperability format, JSON, does exactly that: it takes plain text and adds structure to it to make it easily parseable by machines. Overall, I'm not sure what part of my post you're arguing against. I'm suggesting that instead of having a many different ad-hoc formats, Unix utilities should agree on a few accepted serialization formats and pass information around using those. This would make our shell pipelines less complex and more robust because we wouldn't have to worry about e.g. random spaces or newlines breaking the ad-hoc parsers we write with `grep` and `cut`.
It seems like you agree with that, with the caveat that that serialization format should be built on top of plain text. That's fine. We can agree on JSON as a serialization format. It's not ideal, but it's better than the myriad of ad-hoc formats that we have now.
Sorry if I came off as "excited" -- the main thing I'm not clear on is the framing of M x N with respect to parsing.
From my post:
I also claim that parsing is an O(M + N) problem, while types can create O(M × N) problems — and often do.
So the key point is that writing M + N amounts of code is tractable, but M x N is not. This was captured in the linked "Unix vs. Google" video as "coding the perimeter" vs. "coding the area".
This is not to say that SOME people won't be annoyed by writing M + N parsers! :) Or that writing parsers is easy. It's only claiming that it's tractable for global interoperability.
-----
Of course you could be referring to some different M x N issue, with respect to a specific application, but I don't really see it, and I'd claim it isn't the dominant issue with interoperability and POSIX.
To bring it back to the original subject, POSIX addresses the M applications x N hardware platforms issue (and again, the claim is that it's a compromise, not that it's optimal).
And of course POSIX APIs are text- / byte-oriented, unlike past and future operating systems.
It tames a code explosion and make systems feasible. But yes I definitely agree that we need more structure on top of text. My view is that we need a language with first-class support for serialized tables (TSV/CSV), records/objects (JSON), and documents (HTML/XML).
CSV in particular is very sloppy, and we should take at least as good care of our "languages for data" as we do languages for code (Go, Rust, Python, etc.)
It seems like you agree with that, with the caveat that that serialization format should be built on top of plain text. That's fine. We can agree on JSON as a serialization format. It's not ideal, but it's better than the myriad of ad-hoc formats that we have now.