Another case I'd like us to keep in mind is the "fragemented BAM" case -- I'm not sure if your changes here, or the ones you're about to commit, are able to handle it or not but I thought I'd spell it out just in case.

I suspect most of us are used to dealing with "unitary" BAMs, where all the reads (and read groups) for a single sample are in a single BAM.  Maybe I'm wrong on that assumption?  

But one of the things Carl and I are starting to understand is that a lot of "custom" processing pipelines, which we (at least, I) would like to interact with using ADAM, are producing fragmented BAMs where different BAMs hold different read group data (and even cases where the BAMs are sharded from completely shuffled data, and there may be read groups that are scattered across multiple BAMs).  For the pipeline comparison and validation work we're doing (again, work that still needs to show up here soon as a pull request), we pay attention to whether (e.g.) the Sequence Dictionaries are the same across the fragments and we use the SequenceDictionary code to unify them when they're not, as we build RDD[ADAMRecords] that are really unions of multiple underlying ADAM directories.

Just wanted to put that out here, because if we're looking at building a similar structure for read groups, we might need to think about this situation too.  Just want to be sure that we're not implicitly assuming that (say) read groups with teh same name will have the same ID across different adam files, etc.