Das ist nicht wirklich ein Bug.
Die Floats in LSL sind normale 32-bit Gleitkommazahlen nach IEE 754, mit denen sich sowohl sehr große als auch sehr kleine reelle Zahlen darstellen lassen.
Dabei ist die Zahl im Prinzip nach folgendem Muster aufgebaut:
Zahl = Vorzeichen* 2 ^(Exponent) * Mantisse
Zahl = [V][EEEEEEEE][MMMMMMMMMMMMMMMMMMMMMMMM] (binär), d.h. dabei hat das Vorzeichen 1 bit, der Exponent 8 bit und die Mantisse 23 bit.
Dabei legt das Vorzeichenbit fest, ob es sich um eine negative oder Positive Zahl handelt, der Exponent gibt den Wertebereich an und die Mantisse gibt die relevanten Ziffern an. Mit dieser Art und Weise die Zahlen mit einer 23-bit Mantisse aufzubauen kann man aber Prinzipiell nur auf log(2^23) = 7 Stellen genau berechnen. Weiter hinten liegende Stellen werden einfach abgeschnitten und gehen verloren.
D.h. je kleiner oder größer ein Float wird, desto ungenauer wird er.
Ein Float kann daher z.B. a = 123567.0 * 10^5 oder b= 0.1234567 * 10^0, also a= 123456700000 oder 0,1234567 sein.
Aber eben nicht 1234567.890123 * 10^5 = 123456789012,3 - für diese Genauigkeit ist die 23-bit Mantisse mit 7 Ziffern nicht ausreichend.
Wenn man genauer rechnen möchte mit Floats, dann gibt es eigentlich nicht viele Möglichkeiten:
a) Man benutzt dafür intern Floats mit 64 oder mehr bits, wobei man dann vermutlich diverse Bibliotheken für sein script selbst schreiben müsste um mit seinen Zahlen z.B. Addieren, Subtrahieren usw. zu können.
Und um aus dem eigenen 64-bit Float dann z.B. einen passenden String zu machen.
b) Man sorgt dafür, dass man nur mit kleinen Exponenten, d.h. mit nicht zu großen und nicht zu kleinen Floats rechnet. Wenn man z.B. mit sehr großen Zahlen rechnen muss, dann muss man eben den Wert einer Zahle "aufteilen" in Summen aus zwei oder mehr Zahlen. Und dann auch mit den kleinen Teilen exakt rechnen.
Z = 12345678901234567890,1234567 = (1234567 * 10^13) + (8901234 * 10^6) + (567890 * 10^0) + (1234567 * 10^-1)
D.h. man kann je nach Anwendung oft mit einem "Bias" bzw "Offset" arbeiten, den man natürlich am Ende einer Operation immer berücksichtigen muss.
Und wenn man diese Zahlen dann zu einem String umwandeln will muss man sich wohl auch eine eigene Funktion basteln, eben mal alles in einen LSL-Float zu konvertieren wegen des Typecastings sorgt ja dafür, dass die Genauigkeit wieder futsch ist.