Seriously? THAT’s what you want to focus on?
For one thing because Geoff said you no longer have a dedicated compiler guy.
(see https://forum.xojo.com/t/something-funky-about-uint32-comparisons/57447/163 )
Whether your answer is correct depends a LOT on what you define as “compiler” (eg whether you count fixes in the pre-processing steps as “compiler fixes” or not).
But I’m glad to hear that Xojo can do compiler fixes so it should be easy to fix this … 
The basic problem is that under a 32 bit system a Double can represent a MUCH larger range of integers accurately than an Integer can. So a LOT of code used Double instead of Integer to avoid integer overflows:
The maximum value of “whole numbers” that can be accurately represented:
| 32 bit | 64 bit | |
|---|---|---|
| Integer | 2,147,483,647 | 9,223,372,036,854,775,807 |
| Double | 9,007,199,254,740,992 | 9,007,199,254,740,992 |
| unsigned Integer | 4,294,967,295 | 18,446,744,073,709,551,615 |
On 32 bit systems it made some sense to cast to a 32 bit integer even though I would argue it would have been better (and more future proof) to cast to a 64 bit integer (and yes, you CAN use 64 bit integers on 32 bit systems though it will probably slow down the calculation).
However on 64 bit systems it is simply not acceptable to cast a Double to 32 bit Integers.
Of course. I’m not a theoretical physicist … 
Something that causes int32 overflow errors where none should be is a bug, not a feature.
Basic functionality should be rock solid. Especially where computers and Maths are concerned.
Xojo’s Maths implementation leaves a LOT to be desired.
Btw the two Boeings that fell out of the air because their engines stalled? That was due to a 32bit Integer overflow error.