and I'm nearly certain such a change would require low-level, POSIX-breaking changes. Well, as long as you were happy with it being opt-in (ie, every currently

and I'm nearly certain such a change would require low-level, POSIX-breaking changes. Well, as long as you were happy with it being opt-in (ie, every currently existing program and terminal defaulting to just ignoring the content type as it does now), I imagine you could get 99% of the way there by adding two new command types to the fcntl(2) syscall: F_SETCTYPE Set the content type for the data written to this descriptor to the value pointed to by the third argument, which must be a pointer to struct fctype. F_GETCTYPE Get the content type for the data read from this descriptor and store it into structure pointed to by the third argument, which must be a pointer to struct fctype. struct fctype would just contain a character array. You'd implement it so that the value set by F_SETCTYPE on the writing end of a pipe or named pipe is returned by F_GETCTYPE on the reading end, and for pseudo-terminals the value set by F_SETCTYPE on the slave side is returned by F_GETCTYPE on the master side. You probably wouldn't bother supporting it for sockets or disk files (though files could store it in a POSIX extended attribute if you really wanted to). The writing side would have to set the content type before calling write(), and the reading side would have to get the content type after read() returns.