But it seems then that it is a misconception from scripters to expect the same result with decimals in $base with same inbase/outbase.
That is why anyone who works with floating point needs to read this
My suggestion about using the number as is with same inbase/outbase would bypass the rounding issue.
No, this is, as you said, a bad idea. We would then have to start adding exceptions in every feature/identifier that doesn't quite give the results we want because of how math/floating point works. In this case, this issue is due to needing more precision/decimal places to make $base() give the correct results in calculations, however this extra precision means that the original input cannot be represented exactly as a float.
I have reverted the change to $base() for the next beta.