> shouldn't may be this to be "folded" into a generic FlattenMapper? e.g. if a kwarg flatten_fa (or some other better name) provided with such a dictionary? 

FlattenMapper is much more general than ProductFlattenMapper and may be used in many places. Isn't it better to keep PFM as a subclass, and thus separate the logic? Note there is not code duplication, as PFM uses most stuff from FM and only extends it where necessary.

> Moreover may be allowing such a dictionary to actually be stored/present originally within .a collection and just specified by name here? 

Currently it is stored in the PFM instance as a field _factor_name_values. What is the advantage of storing this in .a as well? 

> (then any I/O method to load such data would just fill it up) and then may be even recreating it on the way back (in .reverse())?

Not really following when/how this would work. What would happen if the array is sliced later?