This is essentially the inverse of the problem addressed in #6024 (which deals with parsing a stream of decimal values into floating-point values), and the behavior cited below probably does not matter for the vast majority of MicroPython's main applications, but we'll mention it in passing on the off chance that someone has a reasonably clean, tight fix for the issue:

When formatting floating-point numbers for display, the displayed value is not always the closest decimal value to the underlying floating-point value.

This behavior is most noticeable when working with floating-point integers (which can be stored exactly in IEEE-754 binary64 values). The exact values that exhibit this behavior probably varies by port. On a Windows 64-bit build of MicroPython 1.14 there are 3325 integers in the range 0., 9999. that are displayed "incorrectly" (the first and last few are shown below):

MicroPython v1.14 on 2021-03-23; win32 version
Use Ctrl-D to exit, Ctrl-E for paste mode
>>> 41.
41.00000000000001
>>> 46.
46.00000000000001
>>> 9996.
9996.000000000002
>>> 9998.
9998.000000000001
>>> 9999.
9999.000000000002

A quick peek at the internal values for these floats shows that they have been stored accurately, e.g.
41. is stored as 0x1.4800000000000p+5, as expected, so the issue that #6024 is attempting to address is not at play here. Rather, it's the conversion from (binary64) floating-point values to decimal equivalents for display that appears to be at fault.