And that's my point. It's a mistake to blindly interpret all keyword values as strings. That is the bug. The bug is not a given keyword's data type being what it is.
Thanks for sharing your concerns.
This topic less trivial than it may seem. I perfectly understand that you consider this as a bug since you assume that the string "-12.5" must be interpreted as a number, this looks quite obvious and simply the way to go.
WBPP is most probably the most used script of PixInsight, used by tens of thousands of astrophotographers around the world that adopt a wide variety of conventions and custom ways to name files and embed/encode data from different acquisition and processing softwares. For this reason, keywords feature grew slowly and carefully, trying to accomodate as much users as possible while trying not to take choices that reveal to be awkward or even wrong to many users. The reason why I was always skeptic in terms of internally convert keyword values into defined data types is that assuming the type may work for some but not for others and this may not always be the correct way to proceed in general, it's very easy to end up satisfying a set of users but displease others.
Let me share my concerns regarding the interpretation of numerical values. First of all, you cannot simply apply the parseFloat() JS function to keyword values since it succesfully converts non-numerical strings like "12:00" into the numbers, making "12:00" and "12:10" both 12 resulting equal each other while they are not.
But let's also assume that we're smart and we use a regexp to test the string format before parsing the values, like the following:
"if this string matches a valid numerical format (as the FITS standard defines for float numbers, for example) then parse it as a float, use the string value otherwise"
Now, if "12.1" should be taken as number, the consequence is that the value "12.10" is the same. But here we're just reasonably guessing, I'm quite sure that someone will come back saying that WBPP is buggy because it matches these values while, in their case, they have to be considered different because they didn't meant a float number. It could be month/day code for the session, as an example, but it could be whatever information you decide to encode into a xxxx.xxxx format., being x a any digit.
Now, we need to assume some conventions on top of which WBPP behaviors are developed, the "agnostic" way is as reasonable as the "attempt numeric conversion" way, as long as the user is responsible of storing the metadata accordingly.
By the way, don't get me wrong, I welcome your concern and it's not something new on the horizon, indeed a pending feature that I didn't implement yet is to specify the type of a keyword amongs a very short list "auto" (the default), "string" and "numeric". Of course, you need to be aware that "auto" interpret values as numeric first and string otherwise, so "12.1" and "12.10" will be both interpreted as 12.1.
I guess times are mature enough to plan its implementation