Good point. But then I go back to my original position: I think there's utility in using the partitioner to re-arrange the computation into distinct, spatially-coherent genomic regions.  In that context, I'm not sure why we'd want to scatter the unmapped reads across those partitions, since each partition-based computation (i.e. the argument to mapPartitions or its equivalent) would just end up filtering them out first.

The GenomicRegionPartitioner is derived from code I wrote in a Genome Bridge-specific repo, for calculating base-specific A, T, G, and C counts from the reads in an ADAM file.  Partitioning the reads by position and then using a partition-preserving transformation into single-letter pileups that could be aggregated later seemed to be a reasonable win performance-wise.