The Original poster's submission (not sure if it is a review) falls dismally short of what a generic templates computational library should be at the bare minimum let alone something useful by the general populace. Quite a statement. I limit my answer to this: the submission is a
preview, as mentioned in my posting.
One other thing I forgot to mention, was when looking at the provided link http://geometrylibrary.geodan.nl/points.html
The distance definition takes 2 templated point types but always returns a double. The lesson here is that the precision required for the the result may be more than the precision of the inputs. In this case the best strategy is to at the minimum return the same numeric type of the points as the result type or better.
The distance of two integers may result in a floating point value. Therefore distance returns a double. Internally, you will see, often, the same numeric types or better is used as you describe. See select_type_traits and large_type_traits.
The other issue is that the points should be of the same type, not differing types. This strategy_traits approach where assuming there will be an implementation for the combination of types is not adequate, what if one of the types can be easily promoted to the other?
Points of different types can be handled. If you use a derived class, you have to provide an appropriate traits class. It is not promoted. At least not in the compilers I use. Besides that, the library user might choose to specify a strategy.
eg: double conversion to my_super_duper_arbitrary_precision_floating_point_type via copy constructor? does that mean I have to provide a wrapper around the explicit call to my implementation of distance with my specific type? Indeed the distance result could use a large_type_traits as well.
Barend Gehrels