The main problem is that you are so touchy that on anything wrote here you react as a childs. Gosh!
Try to discuss more rational and to the point, and you get less sentiment back.
I point here on logical bug and probably Delphi incompatibility, suggesting to test and correct.
I have now explained the design 5 times in various messages. If Delphi does it otherwise, it is either a new int128 type, or some hack.
In both cases to decide what is best, one would need very detailed analysis, since as said, these would be exceptions to the core type promotion rules. It doesn't matter that a few quick tests deliver results that you like at first glance, the core problem is divining the rules from the results.
If results are appealing for a few simple cases, but the rules suck, then this is not the way to go.
Things to try is testing on 32-bit windows ( I assume you mean 64-bit windows with your "64-bit", this might also differ), and testing with some qword and/or int64 typed variables instead of literals, testing if using hex notation matters.
It might be just a int128 emulation inside the compiler for literals only.
I don't know. Embarcadero is notoriously bad in publishing language rationales. But maybe they implemented a native int128 type for 64-bit only. Does it compile in 32-bit ?
Exactly, you do not know, but stii claim that decision regarding this you have made is correct.
Correct would be having no uint64. But instead we have a dummy uint64. That is fine as long as you avoid mixing types (and better: limit the usage to a few cases like e.g. where filesystem API's specify qwords.)
http://docwiki.embarcadero.com/RADStudio/Rio/en/Declared_Constants
According to this, they didn't developed int128 type, but then again, I see no logic why constant literals are probably not automatically converted to int64, as in FPC. I just asking confirmation from someone have Rio - I do not have it.
They don't say 64-bit only, so one must assume that they haven't. Or only emulate it inside the compiler's literal evaluation.
The only general fix is going to a full int128, the rest is just more hacks. That won't solve much, it just changes the windowdressing from one useless case to the next, and just adds more complex exceptions that can have strange combined effects (e.g. wrt overload selection).
But if you implement int128, a week later a patch for uint128 is implemented using the old hack, and the cycle starts up again.