There's a bug in TrianglePickData:
in calculateDistance() there is:
There was some code changed after that topic you linked, and people have since said they no longer experienced that bug. Plus, distance is calculated after the collision is already found.
As for this "bug", I didn't write any of that code, but it could be intentional… sqrt is a very expensive operation compared to multiplying a variable by itself. I'll let the author of this piece of code answer this one though 
Distance is only calculated if you ask for it, so having it return an accurate distance seems reasonable. I've checked in this fix, altered a bit to not do a sqrt on MAX float.
As for this "bug", I didn't write any of that code, but it could be intentional...
Not really. It's inconsistent with PickData.calculateDistance(), which returns real distance to bound.
There's typically less results to process there, and in some cases you don't even have to use sqrt (BoundingSphere). But yeah, if it was intentional it should at least have been noted somewhere, so it could very well be you just found a bug that Renanse fixed now Whenever I do distance comparing and such I intentionally do not use sqrt though. Doing an extra sqrt for can really kill perfomance…
it should probably be a flag instead. When you are simply doing distance sorting, sqrt is not necessary, but if you were using the result for something else, distance should be actual distance.
Actually, if anyone needs actual distance (rarely…) he can do a sqrt himself (i.e. only on the nearest pick).
So probably those sqrt’s could be removed entirely, but in PickData and all its subclasses, and not only in TrianglePickData.
But then again - it would be a breaking change…