Describe the project you are working on

A 2D physics-based puzzle platformer

Describe the problem or limitation you are having in your project

I constantly run into issues when changing floating-point values in the inspector:

• values such as NaN and Infinity cannot be entered (Inspector doesn't allow entering values of NAN, INF, etc. for float fields godot#87664, Add option in Range nodes to allow non-finite float values + export annotation #8984), don't display correctly (Float values NAN or INF are shown as 0 in the debugger and inspector godot#88006), and behave strangely when used as the default value (the first two of these are a regression from 3.x)
• everything entered into a floating point field in the inspector is rounded to the nearest thousandth -- I have had cases where I need more precision and had to either set the value via a script or edit the scene with a text editor (Spin slider: More flexibility for manual float input regardless of range parameters #3524)
• floating imprecision while rounding to the step value makes it impossible to enter 0 into a floating point field (Parallax2D: Repeat size is getting value 2.08165e-12 instead 0 godot#91631)

I mention the actual bugs to point out that these sort of stem from the over-restrictiveness of the Range class and the Godot inspector. However, they should probably be handled separately from this proposal.

Disallowing NaN and Infinity (godotengine/godot#81076) fixed a number of issues where the editor or games crashed when certain fields were set to infinite values, but in my opinion this was a stopgap solution and doesn't really do anything for cases when these fields could be set to NaN via script. In general, I don't see any reason for editing floating points to be this restrictive by default; generally the developer of a game knows what they're trying to do more than the editor does (they might be using NaN in one of their scripts as a special value because Godot currently has no easily-editable way of making optional types in the inspector; they might need a number to be accurate to more than a thousandth; etc.), and making things less restrictive by default in the editor doesn't make things worse for use cases which need the more restrictive behavior; the fields which cause huge problems when set to non-finite values can keep the behavior from godotengine/godot#81076.

Describe the feature / enhancement and how it helps to overcome the problem or limitation

Add options in the Range class which can remove some of these restrictions, and enable these by default for exported variables (but not for Range nodes in games).

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

• Add a boolean field allow_infinite with default value false to the Range class that allows for non-finite values.
• Add a boolean field allow_finer with default value false to the Range class that prevents rounding of values entered by typing into the field (using the slider in SpinBox or the up/down arrows would still round things to the step value).
• Set both of these to true for float properties with no hint, and false by default with properties with hints, similar to allow_greater and allow_lesser. Add hints or_infinite, or_finer and ideally add these to existing properties as appropriate (but that can be done separately, after the features needed are implemented).

If this enhancement will not be used often, can it be worked around with a few lines of script?

If a specific floating point value is needed that cannot be entered in the inspector (e.g. NaN, 0.12345, pi, 0), it is possible to edit the scene in an external editor and write the exact value in there; however, if the field is touched in the inspector (e.g. by selecting it and pressing Enter) it'll often be rounded again. Exact values can also be set in scripts or as the default export value, but these are kind of inflexible and cumbersome.

Is there a reason why this should be core and not an add-on in the asset library?

This is about changing some core behavior in the editor and is less of a "new feature" than a "fix."