@matt.mccormick Thanks for your extensive performance tests! Very interesting! Clearly the new range-based iterators aren’t always faster (anymore) than the “old-school” NeighborhoodIterator classes, especially now that the old iterator classes have received some major PERF updates. 
However, the new iterators will potentially be much faster than the old ones when the neighborhood location has to be reset frequently (for example, by means of SetLocation). As I observed with GaussianDerivativeImageFunction. Also I believe that the new range-based iterators could be significantly faster than the old ones on arbitrary neighborhood shapes (rather than just rectangular shapes). 
Sorry but I’m not really convinced. Allowing to modify the constant padding value after range initialization might make things harder to follow, in my opinion. Especially when the padding value is modified after retrieving iterators from the range (using begin() and end()). It would yield the question whether such a modification would still affect these iterators. It seems clearer to me to specify the constant padding value as part of the range initialization so that it would then clearly remain constant.
(There’s also the design issue that current ShapedImageNeighborhoodRange class does not have a policy data member, as I explained at Custom border extrapolation of ShapedImageNeighborhoodRange by ImageNeighborhoodPixelAccessPolicy - #25 by phcerdan)
Anyway, please go ahead if you would like to merge ENH: Added policy for constant NeighborhoodRange values outside image by hjmjohnson · Pull Request #105 · InsightSoftwareConsortium/ITK · GitHub I haven’t yet got the GitHub/ITK entirely up and running but if @hjmjohnson would like to do the merge, please do!