I agree that slope-one is surprisingly effective, though storing all item-item diffs is expensive. The good news is that almost all item-item diffs carry virtually no info; they're noise. So, I think there's a much better way to dodge the memory constraint: prune the diffs. That can get you much farther than even optimizing away object overhead.
See the constructors that let you cap the number of diffs stored. It can be reasonably smart; it throws out data based on standard deviation of the diffs.
So, I'd prefer to not yet add such a big amount of copy-and-paste. (And, see below, as you say, I don't think this quite works either, or at least there is some evidence it changes behavior.) I think it's fine work though and worth having in a patch; if it's really popular, well there's nothing terribly wrong with it, just duplicative.
For the rest of the code –
I am happy to add more constructors for the running averages in general, sure, plus tests. I think some of the tests need a fix – for example the copy constructor test doesn't test a copy.
I can add the FastByIDMapTest. The copied keySet/values tests don't test those methods, really but I can remove them.
I am not sure why the slope-one tests would need to be changed – this suggests there's something about the changes that might have introduced a bug. I might have to peel some of that back if it looks like the case.
Likewise, I am not sure why the IR stats eval would have changed; this ought not affect anything there.
I would in general not want changes that make fields public or protected.