For better or worse, versioning in Rebol has used TUPLE!. e.g. 0.3.1 is 32-bit Windows, and 0.3.40 is 64-bit Windows
If you go back and look at the old R3-Alpha file %systems.r you can see that it's pretty typical for Carl to have written the versions out with leading zeros...but only in the third slot. So 0.3.01 but not 00.03.01
But ultimately the tuple discards this information. And this has been the way it always worked:
rebol2>> 0.3.01
== 0.3.1
red>> 0.3.01
== 0.3.1
ren-c>> 0.3.01
== 0.3.1
This leads to problems when you are working with string representations outside of Rebol (say in bash shell, something like "0.3.01") and you pass it into Rebol to process as a tuple. If bash went and created a directory based on the string...you won't match if you FORM that tuple later.
You could insist on passing around the tuple as a string, but that undermines the value of having the version be in a tuple in the first place.
I'd say that the simplest solution is just to stop writing tuples with the leading zeros...instead keeping them in their canon form. 0.3.1 for 32-bit Windows, and 0.3.40 for 64-bit Windows. Then make the directories reflect this, e.g.:
https://dd498l1ilnrxu.cloudfront.net/travis-builds/0.3.1/r3-573037b-debug.exe
and not:
https://dd498l1ilnrxu.cloudfront.net/travis-builds/0.3.01/r3-573037b-debug.exe
That leading zero comes with a whole lot of headaches, so I say hunt them down and get rid of them. Because non-Rebol systems are going to only operate on them as strings and they'll leak.