Question: An amusing bug(ette)

In an unrelated thread, I provided the OP with some 1-D code, which contained the Array definition

TC:= Array(0...1001, fill=0)

Note the existence of three '.' characters in the range specification. This was a typo on my part, or my '.' key bounced, or something. The code containing the above definition "worked" with no problem, which, presumably, was why I didn't notice.

The Maple help does state (my emphasis)

Note that more than two dots in succession are also parsed as the range (..) operator.

although I wasn't making use of this fact - I just screwed up when typing the original.

The OP preferred to use 2-D input, and used cut-and-paste to transfer the above code, resulting in 2-D input, which is where the fun started. It seems(?) that when using 2-D input, more than two dots in succession is only interpreted as a straightforward range, if the total number of dots is even.

If the total number of dots is odd, then it appears(?) as if the 'final' dot is associated with the second number in the range as a 'decimal point', (so producing .1001 in the above example). This is then 'coerced/rounded' to an integer - ie it becomes '0', and the above Array definition is interpreted as

TC:= Array(0..0, fill=0)

Consequences in the following code are left to your imagination

Worth an SCR?