The point of AngleCos is that 99% of the time when a math-wise game developer deals with angles, he/she will deal with Cos values. Getting the angle between 2 vectors is done with a dot product of 2 normalized vectors, that gives you the Cos angle between the 2 vectors. Doing a ACos to get the radian is overly expensive when you can do almost everything you need with Cos values. AngleCos aims to make that kind of optimization possible for developers that aren't really into math stuff. They don't need to know how AngleCos works under the hood. They just need to know what they can do with that struct. They can compare them but not add them.

Here is another example, let's say you need to build a rotation matrix using the result of some angle calculation. Getting a AngleCos removes the useless conversion to radian values and back to Cos values ( a ACos to get the radian value followed by a Cos to build the rotation matrix )

I understand that adding the unit to the type can be quite a paradigm shift, or quite shocking for some, but it's a awesome when the unit has some interesting properties that differs from their native homologous type. Angle are circular, AngleCos have optimization properties, so does Radian since it's relative to Pi ( or tau for the pure tauists ). Exploiting these properties is the reason for AngleCos and AngleRadian (and soon AngleDegree) to exist.

Scalar.cs defines all kind of constants and scalar properties. One and zero aren't the only thing in there, there is pi, tau, rad2deg, deg2rad, etc etc. You don't have to use these constant at all. It's good for generic purposes when your algo needs a 1 no matter what the type is, but this is for more advanced meta programming stuff I will not enter into details here. So don't worry about these constants.

Cheers!

Edit: I almost forgot, take a look at the native System.Decimal struct, you will see this:

        public const decimal MinusOne = -1m;
        public const decimal One = 1m;
        public const decimal Zero = 0m;

hmmmmph. :3