Upon further examination it seems that the problem with the commas is also seen in the "Add" track operator, however, it still functions differently from the "subtract" function. For example, when a user uses the "Add" function to add "40,000" (with a comma) after clearing preferences then instead of adding it will just copy the track. But, if a user adds by "40000" (without comma) and then adds by "40,000" (with comma), the "Add" operation functions as it should. So in summary, for the "Add" operation, the comma in the value doesn't affect the track output unless it is the first value you add after clearing preferences.

With the "Subtract" function it is not this way. If you subtract by "40000" (without comma) and then subtract by "40,000" (with comma), the generated track will just copy. So in summary, a comma in the value when subtracting seems to ALWAYS cause the track operation to copy instead of subtract.

Upon even further examination, it seems that a value with commas in it is defined as invalid. When using the "Add" operation, if an invalid value is entered then it adds by the last known valid value.

When using "Subtract", if an invalid value is entered then it reverts to subtracting by zero rather than the last known valid value. This would explain the difference in functioning between the "Add" and "Subtract" operations.

This issue has been fixed so that commas in the value no longer makes the value invalid. There is still the issue of the Add and Subtract operations working differently for invalid values but this has been recorded in the newly created issue IGBF-650.

My testing verifies that this particular issue has been resolved so it will now be closed.