I had a look at the code and the same mistake that was fixed in June 2015 (using a variable that may contain NaN as first argument in comparison, ternary, or min/max operations) was introduced in new code in vtkBoundingBox class.
I’ve fixed the issue - see necessary changes here: https://github.com/lassoan/VTK/commit/92b1ee09385c271a88dc4d38d8ce4e4dc5940d9f
I don’t have more time to work on this, so you or other VTK developers would need to cherry-pick the fix, add a test, run dashboard tests, get it reviewed, and merged.
On a general note: I would stay away from using NaNs. It could be a convenience for users to assign some meaning to NaN (e.g., it could mean missing data), but if you allow such values then they may show up in completely unexpected places (basically anywhere). To properly handle NaN values, VTK developers would need to add more checks and special case detections everywhere, which could impact performance and would be enormous development and maintenance effort and would require special developer skills.
A potential solution, which would not require a huge effort, could be to describe in VTK documentation that NaN values are only supported in those classes that explicitly state this in their documentation (and add notes to classes that are tested to work well with NaNs).