Are you suggesting putting the (I assumed versioned) type system into the file's metadata, so that others can make sense of it? Or, some type system UUID, in the metadata, that can be used? I think anything like this would require many new concepts, like the move away from files being a collection of arbitrary stored bytes.
Well in theory if we are only doing an inheritance, we can just combine file extensions hierarchically in the name.
For example, for CSV files we can use .csv.txt extension, so if shell has no software for CSV files, it will treat them as a plain text, and if it has a software for viewing CSV files, but not for editing or printing them, it will add these verbs from records for txt files.
This is backwards compatible and would require minimal changes to file managers and graphic shells.
A C struct can also be addressed as bytes if one really wants to. The structured way of looking at the data is still more valuable, most of the time.
Another example: you can easily grep through a JSON file sometimes. But what if that JSON doesn't contain newlines? In that case it would be great if the system knew how to convert the data to a multiline string that makes sense for grep. This cannot be done if the data is "just bytes".
Further, JSON data can be represented with less bytes if you know the structure.
