My issue: I have a number in label which I can increase or decrease by 1 or 0.1 by tapping on buttons.

Often, after playing around a little and getting back to zero, instead of showing "0", it shows some gibberish, usually with a capital E in there, like: "-2.7756E-17".

This only happens if I have also used the incremental changes.

You can replicate the error quickly on my tiny testing app: Tap "+1" to get the value "1", then tap "-0.1" ten times in a row to get back to what should be "0" but instead is some messed up number

The gibberish you see is actually a number in scientific notation. What you see represents a very small value. You might use a Math format block ahead of the Number Block to set the number of decimal places. That will take the display out of scientific notation mode.

Why does it happen? A guess is you are touching the buttons very rapidly and that is confusing the Math algorithm by not giving the app time to respond.

Did you notice you have an empty puzzle piece in your Reset.Click event handler? Perhaps that relates to your issue by setting Number to a value that is not a number.

0.1 is an infinite length quantity in binary, like 1/3 is an infinite length decimal number.

You got math sawdust.

P.S.
AI2 might still support rational number data type arithmetic, if you substitute 1/10 for 0.1 everywhere. But some math operations result in floating point results , so avoid those.

Technically, the rounding errors occur at pretty much every number once you get small enough fractional differences that cannot be expressed neatly in the 53 bits of mantissa of a double floating point number. For example, 0.1 + 0.1 + 0.1 will give you 0.30000000000000004. Typically when App Inventor renders a number it does so only to 5 decimal places by default so you don't see the error. However, in the case of numbers near zero, scientific notation is a more compact and accurate representation, so you end up being able to see the accumulated error in a more up-front way since that's all that remains. The use of the floor or round functions may be useful in this case.

I think these days all of the exact numbers are converted back to inexact numbers when they get passed up to the user. It might take me a little while to verify that.

Ok, so it looks like there are only two places where we are converting exact numbers to inexact numbers. The first is in conversion from numbers to strings, and the second is in the division operator. Therefore, you can still get some access to the rational numbers but unfortunately you can't really visualize them because the number to string coercion will convert them from their rational representation to the decimal representation. But, you can still do something like this: