Na eben das zeigt ja, dass das Verhalten eben genau nicht konsistent ist.
Man kann eine Variable mit einer Zahl vorbelegen.
Hierfür hat man ausdrücklich die Wahl (siehe Hilfe) zwischen der Dezimaldarstellung und der Hexadezimaldarstellung.
Wichtig: Es geht um die mathematische Darstellung einer Zahl nur mit jeweils unterschiedlichen Zahlensystembasen.
Diese Darstellung ist unabhängig davon wie diese Zahl mal binär kodiert wird - also ob als Int32, UInt32, Int64 etc.
Und jeder korrekte Zahlensystemkonverter der Welt macht aus 0x80000000 eben 2147483648. Einfach weil das Hexadezimalsystem nun mal so funktioniert.
Jetzt sagt aber AutoIt: Ne im Bereich 0x80000000 bis 0xFFFFFFFF interpretieren wir das was der User eingibt aber anders: Wir nehmen hier an, dass der User die binäre Kodierung einer Int32-Zahl meint anstatt dem Zahlenwert.
Das ist aber eben genau nicht konsistent, da sie dann konsequenterweise bei Eingabe von Zahlen im Dezimalsystem genauso verfahren müssten damit es konsistent ist. Sprich: gibt der User Zahlen im Bereich 2147483648 bis 4294967295 ein, gehen wir davon aus, dass der stattdessen die binäre Repräsentation in Int32 meint.
Denn: Die Zahlenwerte sind exakt die gleichen nur andere Basis ( (FFFFFFFF)16 = (4294967295)10 ).
Dennoch werden die Zahlen unterschiedlich interpretiert. Und davon steht nichts in der Doku.
Ich bleibe dabei dass es ein Bug ist.
Möchte man negative Zahlen, dann nimmt man den Vorzeichenoperator und fängt nicht an Nullen abzuzählen.
Andere dynamisch typisierende Sprachen wie z.b. Python, Javascript und Ruby machen das übrigens korrekt im Gegensatz zu AutoIt.