元スレはこちらですね:
http://nade.jp-pro.net/bbs/bbs1/mbbs.php?m=thread&threadid=16
この問題は浮動小数点数全般に起こることなので、どうしようもありませんね。
（元スレでも VB の場合について言及されていますが、他の言語でも同様の例を作ろうと思えば作れると思います）
内部的には Delphi の Extended をずっと使っているので、
特定バージョン以降に限るバグということでもありません。
もっと言うと Delphi でも Extended 型を Trunc すると同様のことが起こります。
確かに *1.05 という計算においては誤差が下側に出る割合が他の言語と比べて多い気がしますが、
だからと言ってこの現象がバグだという訳ではありません。
この計算では Double で誤差が上に出て Extended で誤差が下に出やすいだけのような気がします。
数値型の浮動小数点の精度には倍精度（Double）を採用する言語が多く、
一方なでしこ（Delphi）では Extended を採用しているためこの差が出る、と。
Extended の方が精度が良いので、当然、計算誤差そのものは Extended の方が小さいハズです。
元スレで既に解決していますが、一応こういう場合のより一般的な対処方法も紹介しておきます。
(a) 浮動小数点計算を可能な限り避ける: 1900*105/100
(b) （小数点以下で）四捨五入する: 1900*1.05を60で小数点四捨五入
(c) 固定小数点型 / 有理数で計算する。
（なでしこにはどちらもないので自前で実装しない限りこの方法は使えません）