Limitations of the merkledag link

I think the inclusion of `name` inside the [merkledag link](https://github.com/ipfs/specs/tree/master/merkledag#logical-format) is very limited for a particular use case, and even that is not general enough. I understand that it makes file-system use case easier to do, but even that I am not sure if it is really necessary. It could always be done through a two-level link: one which is just a link and another, which contains then metadata.

It feels to me that this is also something which is duplicated partially on the files layer.

Is this a legacy thing?

Anyway, while reading [the paper](https://github.com/ipfs/papers/blob/master/ipfs-cap2pfs/ipfs-p2p-file-system.pdf), the section "path lookup performance" I see that you are even using in flattened tree `name` as a path. So that you add `/` between path segments. This has some [assumptions about a platform used which IPFS is running on](https://github.com/ipfs/go-ipfs/issues/2013).

Initially I assumed that `name` is not a path so issues like how to store path separators uniformly and normalize them do not exist. But this seems not to be true. For example, in this case it would be much better if `name` would be an array of strings, in the most common case just an array with one item. But in such flattened tree view arrays would have multiple items.

But this is just a special case. Maybe `name` should not be a string, but each link could contain arbitrary metadata? Then flatten tree could store arrays, files layer could store file names. And some other service providing object-oriented file-system identified by tags could use metadata to store sets of tags on relations between objects/files.