It appears there are two different types of issues reported in this thread, one directly linked to the limitations of double precision floating point values and math, and the other having an unrelated cause.
The first issue is discrepancies in the 14th, 15th or 16th digits between the reported and expected values of coordinates, measurements, and related, with the modeling using custom Cplanes. An example is
These discrepenencies are almost certainly due to a combination of the use of double precision floating point values and math, and the coordinate transformations which occur when custom Cplanes are used. I discussed this in post #8 above. (Note that if higher precision values and math were used, such as Quadruple-precision floating point, there would continue to discrepencies with exact values in the least few decimal digits.)
The second issue is discrepencies in the 5th, 6th or 7th digit after the decimal between measurements made with or the boxes created using the BoundingBox command and the expected values. These discrepencies are too large to be caused by the use of douple precision precision values and math. However the discrepencies appear to be small than the absolute tolerance setting used. Similar discrepencies have been previously reported; for example Finding the lowest and highest points in a surface - #25 by davidcockey
Based on tests described below It appears that BoundingBox uses an approximate method for curved objects, likely involving mesh repesentationw of the objects, and the current accuracy of this method is better than 0.0001. It may be possible to improve this accuracy at the expense of increased computational time and possibly memory use for complex objects and sets of objects.
To test BoundingBox I created geometry with pairs of rectangular blocks, one pair with sharp edges and the other pair with filleted edges. The blocks were created using the World coordinate system, and then copied and oriented on a custom Cplane. BoundingBox test DC01.3dm (2.2 MB)
This issimilar to what Gjis used as an example in https://mcneel.myjetbrains.com/youtrack/issue/RH-81124.
I used BoundingBox to obtain the overall dimensions of the pair of sharp edge boxes and the pair of filleted edge boxes results in the dimensions for both pairs of boxes in both orientations.
Exact: dimensions = 250, 100, 20
Sharp edge, World: dimensions = 250, 100, 20
Filleted edge, World: dimensions = 250, 100.00000000000041, 20
Sharp edge, Custom Cplane: dimensions = 249.99999999999994, 100.00000000000009, 20.000000000000199
Filleted edge, Custom Cplane: dimensions = 250.00002205583289, 100.00003301417769, 20.000020472785252
The result for the sharp edge pair of boxes oriented on the World Cplane is exact. The result for the filleted edge pair on the World Cplane is within the expected accuracy of double precision floating point arithmetic as is the sharp edge pair on the custom Cplane. Discrepencies are in the 15th, 1th or 17th decimal digit.
The result for the filleted edge pair on the custom Cplane have discrepencies in the 5th digit after the decimal. This is much larger than discrepencies associated double precision floating point values and math. This is likely due to BoundingBox using an approximate method for curved objects, likely involving mesh repesentationw of the objects, and the current accuracy of this method is better than 0.0001. It may be possible to improve this accuracy at the expense of increased computational time and possibly memory use for complex objects and sets of objects.