I have looked at the changes introduced with collision code and I think that xith3d is getting into very dangerous situations because of Point/Vector/Tuple/Coord3f.
In java3d, everything worked on Point3f and Vector3f, almost none of methods accepted Tuple3f. While this caused a lot of headache when you had to move data there and back just to match some method signature, at least it was very helpful (for me) math-wise - if you had ray method, you new what Point and Vector meant without looking at javadoc or parameter names. With pair of tuples, you need to be a lot more careful - and mistake will go unnoticed silently and can even work correctly in some cases !
Now I see that Coord3f extends Vector3f class was added to unify Point3f and Vector3f. Again, I understand the reason - Tuple3f has not exposed enough methods to be useful, so even in xith3d you had to sometimes copy data there and back or rewrite basic stuff like dot product yourself just to have it work on tuples you got from elsewhere (this would be not a problem if they would be Vectors as they should, but...). But then comes the transform and while Coord3f extends Vector3f, MatrixExt4f transforms it as a point... and this is a one step too far IMHO. Look at following examples
I can transform coord as point using
Matrix4f matr = me;
I don't know if it hits you as much as me, but if I see a code which just assigns a pointer to superclass and this changes a result of method call...
Same goes for
Vector3f vec = coord;
In first case it is transformed as vector in second as point.
This is bound to be a cause of major and hard to detect errors in both core lib and user programs. Solutions ? I do not see ideal one, but here are some ideas:
Rename transform(Coord3f) method from MatrixExt4f to transformAsPoint(Coord3f) and add second one transformAsVector(Coord3f). Then make Coord3f to extend Tuple3f and copy vector methods there in addition to point ones - this way it will not get mistaken by accident. At the same time, transform methods as different enough to not be available with other meaning in plain Matrix4f.
In every method which has incoming Coor3f parameter, stress if it is looked at as point or vector if it makes a difference.
In some cases add explicit Point/Vector name to method, as you cannot rely on parameter signature matching to do a job, so you need to go EIFFEL route and encode everything in method name.
My personal choice would be to go back to java3d route and use Point3f/Vector3f in meaningful way, even if it costs developer a bit of extra work. But as it is one of design guidelines of xith3d to not have such distinction, at least let's make it very hard to make mistakes.