llSay(0, (string)((integer)(100 * 0.9)) ); => result 89

llSay(0, (string)((integer)(100.0 * 0.9)) ); => result 89

integer int=(integer)(100 * 0.9);
llSay(0, (string)int); => result 89

integer int=(integer)(100.0 * 0.9);
llSay(0, (string)int); => result 89

but of course
llSay(0, (string)(100*0.9) ); => result 90.000000

An integer is just a number, but limited to a fixed range. To increase the range of an integer you must increase the number of bits, regardless of the precision you want or is useful.
A float on the other hand has a fixed precision but that precision can be shifted up and down a much larger range.

A float has three components, the sign, mantissa and exponent. The sign is just a single bit but the mantissa and exponent are integer values: the value of the float value is:
(sign?-1:1) * (1 + mantissa / (mantissa_max + 1)) * 2 ^ exponent;

As you can see, the exponent is on base two and not base ten; with the mantissa calculation it falls in the interval [1,2).

How does this apply to this situation?

With a float it is impossible to accurately represent 0.9, the best you can get is 0.899999999, when you multiply that by 100 you get 89.9999999. When you did the integer truncation, you got 89.

Lessons to learn from this:
1) Some numbers are impossible to accurately represent as floats.
2) You will accumulate errors when you use floats.
3) Don't use floats unless you need to.
4) Consider using llRound instead of truncation.

Now for the reasons why this will never be fixed:
1) The floating point standard previously mentioned is an industry wide hardware standard (originating in the 1980's). If you want something different you have to implement it yourself in software or fabricate your own CPUs. Both are expensive and beyond the scope of what LL does.
2) It would break existing scripts that (inadvertently) depend upon the rounding quirks.

1)
llSay (0, (string) ((integer) (100 * 0.9))); => result 89
llSay (0, (string) (100 * 0.9)); => result 90.000000

It will get confused.
If the phenomenon of internal processing float only, those results should have the same values.

2)
Result in LSL2,
llSay (0, (string) ((integer) (100 * 0.9))); => result 90
so, mono is not compatible to LSL2.

// SVC-3328
default
{
    state_entry()
    {
        llSay(0, (string)((integer)(0.7 * 10.0)));  // 6 in Mono, 7 in LSL
        llSay(0, (string)((integer)(10.0 * 0.7)));  // 6 in Mono, 7 in LSL
        
        float var_float = 7.0 / 10.0;
        llSay(0, (string)((integer)(var_float * 10.0)));  // 6 in Mono, 7 in LSL
        llSay(0, (string)((integer)((7.0 / 10.0) * 10.0)));  // always 7
        llSay(0, (string)((integer)(7.0 / 10.0 * 10.0)));  // always 7
        
        var_float *= 10.0;
        llSay(0, (string)((integer)(var_float)));  // always 7
        
        var_float = (7.0 / 10.0) * 10.0;
        llSay(0, (string)((integer)(var_float)));  // always 7
    }
}

Never trust a float to integer conversion
Unfortunately Mono seems to be a little less reliable than LSL, maybe it can be fixed.

The same is true of 10.0*0.7. 0.7 is binary 0.1_0110_ or 0.1|01100110011001100110011|00110... which will clearly round DOWN, making the result of 10.0*0.7 slightly LESS than 7.0 and the result of truncation to an integer should be 6.

That, and people expect simple calculations that an elementary schooler could solve to give the correct result. They don't care how things go internally in the bit values, they don't care how they would display without a modern implementation that handles corrections to the dilemma of internal float representations; they expect such simple things to give the correct result defined by the rules of mathematics, unless you go into the really long/high floats where such things get unfeasable to correct.

The server fix is out on agni now. Next is to check in the compiler changes for a later deploy

[10:40] Object: 90
[10:40] Object: 90
[10:41] Object: 90
[10:41] Object: 90
[10:42] Object: 90.000000