As for nonzero being correct, please refer back to sine of any angle = length of side opposite from the angle/length of the hypotenuse, cosine any angle = length of the side adjacent to the angle/length of the hypotenuse… These are the most basic definitions of these functions before any numbers get thrown in the mix. Good luck convincing anyone that zero divided by any number is anything other than zero or that any number divided by itself, is any other result than 1. The value of the “any number” whether symbolically implied or explicitly stated is irrelevant unless “any number” actually is 0, exactly.
You don’t need 12 (or more) different power series expansions to accomplish trig functions. If you understand what the code names represent (sin(), cos()… et al) you know that any can be determined from the most accurate calculation of any two (one the inverse function of the other) power series expansion for angular values 0-pi/2 and a bit of mathematical shuffling to adjust for trig identity properties, identity reflection and quadrant locality of the input angle (that has been reduced to it’s equivalent value below 2pi). This may be quite edifying if you really want a better explanation and more information.
Which led me to pointing out the SIN(PI()) problem, since the accuracy of the used expansion seemed adequate for display limitations at least up to sin(PI()/2), but not necessarily beyond that… Why? Because it means the value of PI() in this issue is not the relevant concern. You can easily see that PI() is accurate as a double. This means the accuracy of the trig functions only has single precision. You can correct the issue one of three ways. 1) Rewrite all the power series code to have double precision. 2) Limit calculations back into a range where errors due to foreshortened accuracy at least behave properly at non-value related boundaries. 3) Do both. Regardless of actual decimal values involved: sin(pi/2) and cos(0) will always = 1; sin(0) and cos(pi/2) will always = 0; sin(pi/4) and cos(pi/4) will always = SQRT(2) / 2. If you determine the floating point values of the definitions, and then compare results of calculations against them you can always limit return results to the definition accuracy vs floating point accuracy and thereby not carry errors through in those places. For trigonometry the 0 and 1 are needful, the point of symmetry quite helpful, others would be merely convenient but not required (yes there are more). (They used to do all this with tables and 16" or so of slide rule, if you can believe that. Can you say “a nightmare of work” for very limited accuracy? Oh yeah, in the snow, uphill both ways. -.O )
Finally, it isn’t a bug report per se, as it isn’t technically a programmatic bug, it’s a request for more accurate handling of trig functions. Perhaps, this also is not the correct place for such things. You have my apologies. Still, I was hoping it might catch their eye.
If it’s a concern about the power series hit, possibly also provide additional functions SINPREC(), COSPREC(), etc etc
Global scale positioning calculation accuracy is impaired here. Not a common use of your average spreadsheet I guess. But that’s the only reason I ever notice these things in the first place. I can’t for the life of me believe I’m the only one, even if the group is small. 
I may write an extension for this (but it will be a kludge for most everyone - refer back to tables and slide rule might be faster), or perhaps one has already been done… the point however: Native support is always preferable for common functions that serve interdisciplinary concerns.
Thanks for the redirects! The others were also quite edifying!!