Looking at it, it might be that there is one local copy too many (edit after looking some more - I think it's correct as-is). However, note that the code you see here is the result of more than eight years of revisions and at least one of the two cases you mention was located in the HeadUpDisplay class in the past and was transferred over to PlayerEntity at some point. Back then, there could be indeed a very valid reason for doing it this way, which may or may not be applicable now. In fact, there is a comment in the old HeadUpDisplay code (rev. 3f091ec), just when it is about to set the uni_entities, saying: "// use a non-mutable copy so this can't be changed under us." so that must have been the reason back then and the code survived in this form until now.
About my initial proposal: perhaps less heavy-handed would be to make "massLockable" an integer that can take three values:
0 -> no opinion
positive -> forced masslock
negative -> forced "mass-unlock"
So something like:
// before scanned entities loop
bool ms=[self masslockable];
// inside of the scanned entities loop
massLocked|=(ms>=0)&&[self checkEntityForPudding etc.]; // if ms<0 massLocked will keep its initial value (false)
Aside from my "planetary masslock" personal agenda, I believe other OXPs could benefit from being able to force a masslock like for instance "breakable Torus drive" which had to use quite dirty tricks in order to do that.
Would you accept a patch that does that?