Differentiate Targets with Trailing Zeros

A would say that I do agree with this in concept, and perhaps more specifically that EOS would understand that .1 is the same as say .0001 and thus .11  is really more like .0011 -- this makes be think of when using a spreadsheet to sort data, where if it knows the data is numbers, it will handle this properly, but if it thinks that the data is text, it will handle is errantly like shown in EOS

No I think this is confusing. I don't want it to magically assume a different thing is the same thing, in any context. It shouldn't think .0001 is 0.1, it shouldn't assume 0.1 is 0.10. If I type in something different, it should be a different target.

While you can say I want cue 10.1 to  10.9 to all be in order, and then 10.10 to come after that... That is all well and good... so if we keep counting up 19 point-cues -- we end at 10.19

But now I need to add a cue between .1 and .2, and I want to call that what? 10.15 does not work -- how is that going to be differentiated between the cue between .1 and .2 versus the fifteenth point cue?

The only two real choices are:
1) We introduce point-point cues -- so what would fall between 10.1 and 10.2 would be 10.1.5; or
2) We need leading zeros... so what falls between 10.01 and 10.02 is 10.015 -- and that, coincidentally is how EOS currently works.

So without going to point cues we really do need "leading zeros" -- and possibly some system that automatically inferred that the moment I go .7 to .8 to .9 that when I say .10 that we need to basically auto-magically add a leading zero on all the single digit cues...

Going back to your software analogy, the first option is how it is typically solved, in that we don't try to simply add a digit after version 1.1, we either increment it to 1.2 or if we need something more granular we add another decimal point.

Unless you have a different suggestion on how you think not only how you increment past single digits works AND still supports retroactively going back and adding cues inbetween.

While you can say I want cue 10.1 to  10.9 to all be in order, and then 10.10 to come after that... That is all well and good... so if we keep counting up 19 point-cues -- we end at 10.19

But now I need to add a cue between .1 and .2, and I want to call that what? 10.15 does not work -- how is that going to be differentiated between the cue between .1 and .2 versus the fifteenth point cue?

The only two real choices are:
1) We introduce point-point cues -- so what would fall between 10.1 and 10.2 would be 10.1.5; or
2) We need leading zeros... so what falls between 10.01 and 10.02 is 10.015 -- and that, coincidentally is how EOS currently works.

So without going to point cues we really do need "leading zeros" -- and possibly some system that automatically inferred that the moment I go .7 to .8 to .9 that when I say .10 that we need to basically auto-magically add a leading zero on all the single digit cues...

Going back to your software analogy, the first option is how it is typically solved, in that we don't try to simply add a digit after version 1.1, we either increment it to 1.2 or if we need something more granular we add another decimal point.

Unless you have a different suggestion on how you think not only how you increment past single digits works AND still supports retroactively going back and adding cues inbetween.