On one hand, if one is looking at the output, it makes perfect sense to have a separate meta section per document. However, when one looks at it from a client API perspective (how one asks for the value of a particular metadata value) having two different ways to access values ("real" fields vs "meta" fields) doesn't seem desirable.
I'm trying to look at it from an internal datastructure perspective, and a client code perspective. From an internals perspective, keeping the data isolcated makes sense – one set comes straight from the Documents in the index, the other is computed – so they should be seperate datastructures internally in solr, one hanging off the other.
Then the response writer can decide how it wants to deal with those data – for response writers where nested data structures are easy (most of them) this data can be represented cleaning ... or we could add options to flatten the data (using some prefix type option to say all metadata data properties should become fields with the same name prefixed by "_") so that the client can't tell the difference between them ... if we make the internal representation a flattened list of pairs, then we tie the hands of hte response writter.
Ditto for the client library – the more structure we maintain as the data makes it's way to the client, the more options we have as to if/when we flatten it. preserving structure allows code to flatten at anytime if it wants to, so let's go with the option that has the most flexibility and get the best of both worlds.