when you reduce the range to the desired one (100000..200000) you map a huge number of UUID values to the same number

What do you mean?

Let us assume that you generate 2 digit numbers, all different: 11, 20, 51, 22, 70, but you only need one digit random numbers. You can return the LS digits: 1, 0, 1, 2, 0. They are not different, even though the original 2-digit numbers were. The request was to generate 100,000 different random numbers between 100,000 and 200,000. You cannot return 64-bit integers instead, so you have to reduce the range, for example, taking your 64-bit numbers mod 200,001 and add 100,000. Here the mod operator has identical results for 0, 200001, 400002, 600003…, that is, you don't necessarily provide unique numbers in the desired range.

There are many fast invertible functions published with very complicated structure (like ciphers), which provide pseudorandom sequences with absolutely no repetitions in their range

What like fibonacci+n? Although AutoHotkey doesn't have support for generators a function could yield a static variable, so I don't see how complicated that would be.

Fibonacci(n) is not invertible and defined on all integers, while we need a finite range. What I meant is, e.g. f(x) := DES(key,x) is a key dependent function, which is invertible by the decryption function g(y) := DES1(key,y): DES1(key,DES(key,x)) = x. Because of the invertibility, f(x) = f(y) if and only if x = y mod 2**64, therefore f(0), f(1),…f(2**64-1) will be all different. But it does not help us solving the problem at hand.

There is another issue with the above uuidInt() function. The Random command is initialized with A_TickCount, which is reset at each start of the PC. We can assume 0..12 hours of operation when the Random command is first called, and it is seeded with one of 12*60*60*100 = 4,320,000 possible values (10 ms tick resolution). The result is only 4 million different random number sequences you could ever encounter in AHK.

Then you mix in A_Now, which is the same for everybody, except the seconds and ms values. Here you add 6,000 possible variations, only. The result is that if hundred thousand people generate these UUID values about the same time, the chance of a collision is close to 50%, far worse than the quoted trillions and billions let us think. If you used the performance counter in place of the tick counter, it could have improved the collision resistance only by 100 fold. Still not acceptable for cryptographic applications.