It would help to list the thorns that do this here, and probably open a separate ticket for each of them (in case it's not too many).
I currently know of
none other so far
It turns out the thorn that gave me most warnings was a private thorn (author has been notified).
The SphericalSurface routine is actually fairly complicated since it first accesses grid functions then reduces then accesses some more based on information just collected.
Is this routine (SphericalSurface::SphericalSurface_SetupRes) used often? I believe it offers the capability to examine the grid structure and then choose a resolution for the spherical surface that corresponds to that of the 3D grid. While superficially convenient, this is (a) not adaptive, (b) could be done in the parameter file (since one knows the resolutions there), and (c) does not permit convergence tests.
If this feature is rarely used, then it does not need to be corrected.
I just found that RotatingSymmetry90 also contains a reduction call (in rotatingsymmetry90.c line 175). However since it uses TAT/Slab it "can only be used if there is a single local component per MPI process" anyway. Also moving the affected lines outside into a LEVEL mode routine defeats an optimization to quit early if there is nothing to do and the routine in question is not a scheduled routine to begin with. It does however make runs with RotatingSymmetry90 produce very large log files (if -L3 is used).