I see a similar behavior from the Drawing Preferences, with respect to Printing - Page.

I didn't start noticing this behavior until I changed my computer to an M4 based Mac Mini running Tahoe. With that change, I started using the ARM based version of QCAD. So, I'm wondering if the problem is ARM based rather than on other operating systems, including Intel based Macs, like my previous one.

Claude included major/minor swapping in REllipse::getVectorTo().
This is an existent resource and already used in most cases.
I never encountered a major radius less than the minor but it is plausible.

For a ratio over 1.0, correctMajorMinor() caches the minor point (Line 1205).
Sets a corrected ratio (Line 1206).
And then it sets the major point using REllipse::setMajorPoint() (Line 1207).

setMajorPoint() calls REllipse::correctMajorMinor() again.
This time the ratio is less than 1.0 and nothing is altered.

Because correctMajorMinor() is setting things straight it can simply update
the public attributes: 'ratio', 'majorPoint', 'startParam' and 'endParam' in this order.

correctMajorMinor() is typically called for:
- The valid REllipse constructor.
- When setting the REllipse major point, the ratio
and thus also when setting the minor point.
- When setting the properties of an REllipseEntity.

There is a second analog to REllipse::correctMajorMinor().

The method REllipse::switchMajorMinor() does practically the same but then based on an external test.
In open source only used in RShape::getIntersectionPointsEE (Line 1275 and 1279).
Then called when the major radius is less than the minor radius.

The main difference is that it is skipped when the ratio is less than 1e-9.
fabs(ratio) in line 314 is odd because a negative ratio is invalid … Not rendered.

switchMajorMinor() triggers correctMajorMinor() twice.

It first set the major point equal to the minor point based on the former ratio.
This triggers correctMajorMinor().
Then it sets the reciprocal of the ratio.
This also triggers correctMajorMinor().

switchMajorMinor() can also update the public attributes in direct.

For the record: REllipse::getTangents also swaps major/minor in direct when the point is on the minor axis. This method handles an ellipse as full and doesn't correct end parameters.

Regards,
CVH

Layer is not frozen.

See also:
https://forum.qcad.org/t/manage-viewport-layers-not-persisting-save-and-reopen/11902

In RCircle::getDistanceTo
getDistanceTo2D is based on getMagnitude2D().
This should be compared with RS.PointTolerance (1e-9), not squared (1e-18).

! ! !
Only true in an arbitrary (unlimited) precision.
The method using the magnitude or the squared magnitude cannot be compared in floating point.
The squared magnitude will hardly ever have a meaningful 18th digit after the comma.
As it is the subtraction of the vector components with no more than 17 significant digits.

A method missing here is RVector::getSquaredMagnitude2D() avoiding + 0.0*0.0 for dz²

Here you use a circular tolerance area in 2D: Less than 1e-9 away in any 2D direction.
Or a spherical tolerance in 3D.

Positions are typically compared using an axis aligned square shape as tolerance range in 2D (RVector::equalsFuzzy2D) or a cubic box in 3D (RVector::equalsFuzzy):
Less than 1e-9 to 1.414214e-9 away in any 2D direction
Or less than 1e-9 to 1.732051e-9 away in 3D.
40 to 70% more tolerant depending 2 or 3D and the direction.

Regards,
CVH

PS:
I can start a comment on GitHub like before but that is no longer accepting inputs.

See:
https://forum.qcad.org/t/qcad-shading-of-hatches/11828

https://forum.qcad.org/t/crosshatch-problems-using-latest-version/11776

The exception is skipped silently and the configuration is not reset.

Nowadays standard dialog buttons or flags are created using the makeQMessageBoxStandardButtons library function.

new QMessageBox.StandardButtons(…) seems functional too.

.setStandardButtons(A | B) and .setDefaultButton(B) is seen as another method.

Regards,
CVH