I see it now.  I don't see any way around the need to call score_surface_current in the cross_surface routine: wherever that subroutine lies needs to depend on tally.F90.  However, the select case that modifies the coordinate to handle surface reflections definitely seems like something that logically should live in geometry.F90.  My feeling is that cross_surface should be broken up into two subroutines.  For example, the whole leakage if-block and the the first part of the reflection if-block can stay in tracking.F90, still called 'cross_surface', and then everything after the call to score_surface_current in the reflection if-block can be in geometry.F90 in a new subroutine called 'reflect_surface', or something like that.  This makes sense to me since the action of crossing a surface is logically closer to "tracking", whereas the coordinate manipulations for a reflection are a "geometry" operation.  This might be unnecessary though... let me know if you have thoughts on the matter @bhermanmit and @paulromano.

Of course, another way to leave all of cross_surface in geometry.F90 would be to remove the dependency on geometry.F90 from tally.F90 by moving your distribcell stuff into a new file.  This is attractive to me, since it would be nice to not need any dependencies on geometry when tallying (your stuff only depends on geometry_header.F90 and not anything actually in geomtery.F90, correct?).