Discovered this bug working on a drawing with a center circular element. 

If the document scale for user units is not set to 1, when a user attempts to enter a value for Rx, Ry in the Ellipse path object properties tab, they reset themselves based on the non-unity scale factor. 

I replicated this on 1.4 and 1.4.2

Attached a simple SVG I saved which showed the issue. It happens for in and mm document units, and non 1 scale (both scale < 1 and scale > 1). 

(Moderator edit for clarity: strikethrough on "path".)

Seems the object properties are written in px. This is consistent with how the XML is written in the document.

FWIW, optimal behavior seems to be leaving the scale widget alone if units=px and scale=1. Then, alternate units can be set, but the scale will adjust automatically without the need for user intervention:

• Units= Inches: scale= 0.010417"/user-unit
• Units=mm: scale= 0.264592mm/user unit

https://wiki.inkscape.org/wiki/index.php/Units_In_Inkscape#Introduction

I'm on windows, and that is what I had originally, 1 user unit = 1 px. That .264592mm/user unit led to my attempts at setting an RX to 1100 to reset to over 4400. I did a full clean install for 1.4.2 with completely fresh preferences. 

I did a full preferences reset, created a new drawing on A4, which created a document with mm units and the 0.264592mm/user unit.

I created a new Ellipse using the ellipse tool using ctrl + shift to make it a circle. I went to object properties and typed in 300 and it reset to 1133.858, which happens to be 300/.264592. 

Attached recording of attempt captured with LiceCap
 

Seems the object properties are written in px. This is consistent with how the XML is written in the document.

To type-in the values in the document/display units, I'd use the ellipse controls above the top ruler.

Ok, thank you for the screen capture.

I'm not seeing this behavior in 1.4.2 Win10.

God, I'm dense.

I am able to reproduce in  Linux mint and Win.

Looks like this bug:https://gitlab.com/inkscape/inkscape/-/issues/5307

It is perfectly fine if the object properties are in pixels. However for a proper user experience, it should assume what is typed in are those same pixel units; that if I type 300 into those entries, it'll accept that as 300 pixels.

As it stands, these entries are unusable from a user perspective when scale is not 1, because if I type 300, it'll assume I meant 300mm and convert to 1133.858 pixels. Rather, in order to set it to 300 pixels, I would need to do the math and type in 79.3776 to counteract the assumptions made by the user interface. Further, the + & - buttons are technically broken under this UX, because clicking those is equivalent to the user typing in what was in the entry with an increment or decrement, again leading to both causing the value to explode when scale is less than 1.

This should be considered a UI/UX bug and added to the backlog to address in a later update. In the interim, the workaround is either as you said, use different entries, or to set the scale to 1 to enable these entries to be used again. 

Excellent, my reply was being typed before I noticed you edited or added a second post - that issue link does look like what I saw. 

I'm gonna get beat up for this but whatever. 
I reported a similar issue: https://gitlab.com/inkscape/inkscape/-/issues/5446

Tyler - this is some of the "fossil" code pre v0.92 that I spoke of in previous threads that give "crafters/makers" headaches. I nicknamed it the "SVG Tower of Babel" 🤣

I haven't  looked at issue 5307 but I bet it is similar to several other issues. Let me go look!

Edit: Yup - very similar. Things get wild if document scale doesn't equal 1. Gets even crazier when the transform behavior is set to preserved. 

The only way to get things correct is to follow this:

https://maakplek.nl/wiki/doku.php?id=from_inkscape_to_fusion_without_scaling_issues

Then - I can set any document unit/measurement unit at that point and everything works correctly. The only issue is that everything in the XML is converted to pixel units with the inherit rounding errors due to the conversion factor.