imho, SolrDocument's role is best kept as a kind of value object used only for communications with remote clients. I don't think it should appear much in the underlying codebase, where org.apache.lucene.Document is (i) already used heavily, and (ii) does everything you need it to, including storing arbitrary objects and permitting multivalued fields, albeit by different
I don't tend to follow discussions of updating internals that closely (that's more the forte of Mike, Yonik and Ryan) but one thing you left off your list is schema awareness and FieldType encoding. The lucene Document API has a lot of flaws in it, and exposes a lot of options that has no meaning in Solr because the schema controls those options per field/type ... my understanding about hte intended use of SolrDocument in the internals is to provide a clean solid API for people writing Update Handlers to use when specifing field values (without being distracted y the other missleading methods in the lucene Document class) and to provide a clear abstraction between real values and field type encoded values.
ie: Update Handlers construct SolrDocuments which always contain real values, these UpdateHandlers can be largely ignorant about schema information. There is one mechanism for converting a SolrDocument to a lucene Document, this method knows about the schema, the field types, and the field options. all low level code then uses the lucene Document.
-Hoss
