I looked at the dimension in the file attached to the bug report in AutoCAD and Rhino.
The difference in the value Rhino displays and the value AutoCAD displays is the result of the way a graphics preview anonymous block is stored in the file and used by AutoCAD to display the value but is not used by Rhino.
That is a mechanism from early AutoCAD that, I think, was first meant to save time when reading a file with lots of dimensoins. It’s also useful to programs that read dxf files and can’t do the evaluation from the geometry in the dimensions.
Rhino evaluates the dimension according to the geometry and the dimension style that the dimension uses.
In this case, the display block doesn’t match the evaluated dimension. The actual distance measured by the dimension is 0.3558. The dimension style settings that affect the evaluation (style: Dimstyle_1) are Measurement scale factor: 4.0 and Precision 0.0
So when the dimension is evaluated in Rhino, the distance is multiplied by 4 to get 1.4224 and rounded to one digit past the decimal point to get 1.4"
The same result is gotten by re-evaluating the dimension in AutoCAD. The least invasive way I can think of to do that is to copy the dimension, which results in the copy displaying 1.4"
An application writing a dxf file can put what ever it wants in the display block and that will be what is shown by AutoCAD until the dimension is re-evaluated. Unless we were to change Rhino so that it displayed the value based on the display block rather than the geometry and format settings, there’s no way to guess what some program might have put in the display block.
It would make the value pretty unstable to do that since anything that caused enough change in Rhino to cause an evaluation would change the value down the road. I can see that this can be frustrating in this case, but I think it would be as frustrating in other cases if we were to attempt that change.