I am noticing that if I set the Blender file to inches, in geometry nodes, some nodes respect the global settings, some don’t.
For example when creating a mesh line, the inputs are in the default units. However, other nodes like Combine XYZ and Value appear to be based on a meter.
Suggestion wherever there are value inputs, they should respect the unit set in the world settings.
Should this be filed as a bug?
Or perhaps, there should be another kind of input node called Length that is independent of float that respects the file’s units, as I suppose there are many instances where a plain value may be needed as well.
If there is a Length input node, there the group input could also include a new type of input called Length, so the units display correctly in the geometry node modifier
I think someone is on this subject already 
saw a task about this precise question few weeks earlier
I could help, but they won’t implement lol
IMHO if the behaviour is not consistent, like if you change the units to inches as you say, some nodes respect it and some don’t, then it should be considered a bug, it being a high priority or not is another matter, but by all means I would consider it a bug, behaviour should be consistent
Nodes always operate on Blender units internally, which are equivalent to meters. All the units you see in Blender are just a fancy UI layer on top of the internal data that displays numbers with a conversion and unit symbols. That’s a good thing, since the code doesn’t have to worry about units too much.
The problem here is that the UI property subtype (distance in this case) isn’t propagated to other nodes. Theoretically we could analyze the node graph to tell that the value node should use distance units. That’s also related to propagating types (color, vector, etc) to make that workflow more automatic.
This is a pretty involved problem, but I hope sometime we can solve it generally. Or at least allow some simpler improvements like choosing the property subtype when creating a node group.
That would be the quickest fix - have a property subtype called “distance”, for example
That’s implemented here: D15715: Nodes: Add subtype selection to socket editing
Should land soon, I hope.
Great, next step could be to have these kinds of pre-multiplied subtypes in the float node?
