Run the following code (which, yes, is valid, but that's a story for another time)

Code:

and note the return value. The return value changes depending on the letter put in place of "A", and seems to depend heavily on state. A fresh ROM image of OS 5.3.0, for example, will have every letter return 0, and then just θ on subsequent runs. On-hardware, though, 5.3.0 yields an inconsistent mix of letters.

If anybody happens to know what's going on, please dispense your wisdom.

If you stored to any variables before the For( like kg583's code does, it leaks the space taken up by the last non-program variable in the VAT (whether set in the program or outside of it)—that is, the variable is no longer listed in the Mem Delete screen, but RAM (or ARC) FREE does not increase as if it were deleted. If this is the variable A (in the code above), the result is 0 because it gets reinitialized to 0 when read from; otherwise, the value is still available, so it returns 1. (It can fail to be A if you either store to another variable after it in the program or else create A outside the program & then create another variable.) Also, if the variable was in the archive, it will reappear after RAM reset.

If instead you did not store to any variables before the For( but instead make it the start of the program (e.g., remove the "1→A:" part from kg583's code), it does not leak any space.

This happens in every context I managed to test (including immediately after resetting the calculator), so I am not sure if anything other behavior can happen. It also seems to be consistent between C/5.3.0 & N/5.4.0 on real hardware & also an N/5.4.0 ROM dump in CEmu.

My TI contact said that they're aware of this issue and it is to be fixed for a future version

(the way it was phrased implies they were already aware of it, although no idea since when)