Well, there's JSON and variants. Probably a lot simpler than what you had in mind, but if Unix pipes were based on JSON (and had a suitable shell language to work with it), that would already make many tasks easier, like

- Grep the output of ps, without having to count column numbers or do special work to preserve the header line after filtering.

- Search for files matching some conditions, without remembering the weird and unique syntax of find(1) - instead you would write something vaguely along the lines of

    ls | filt {< $1.size 500} {eq $1.type file}

where the stuff after the pipe is the shell language, so theoretically more memorable than

    find -size -500c -type f -maxdepth 1

As a bonus, if you want to cache the output for multiple searches rather than going through the the kernel every time (OS X find is rather slow on huge source trees), you can save the output of ls to a file and keep the rest the same. Good luck doing that with find.

- Handle filenames with spaces and newlines without issues. Simple, but newlines at least are near impossible to solve in the standard shell environment - only a few select tools support null-separated lists. Spaces are easier... unless you want such extravagances as multiple filename columns in a table.

Of course it's not that simple: structured data can sometimes be hard to work with and formatting for display is an issue; Unix's "everything should be plain text" philosophy didn't come out of nowhere.

But I honestly believe that it's time to reexamine that tenet.

Let's take a concrete example: Say you have a programming language L that has a parser that is implemented in lang. A, and an interpreter implemented in lang. B. Now if you want the interpreter (in B) to interpret the program, you need some structured data to come from the parser (in A). Abstract syntax trees (ASTs) are the usual conceptual tool for this. Now assume that the parser outputs an AST that is described by something, like for example an algebraic data type (ADT). Assume that the structure of the ADT conforms to some type protocol. Now the interpreter can implement the ADT in its language (B) and thereby take the ADT directly as input. Now you can use a "typed pipeline" to easily combine these two programs:

> parser directory/file.lang | interpreter

Does this make sense? Would it have some utility?

RPC has to solve the type protocols issue often. Eg Google's protocol buffers.

Protobuf.