The exact dimensions mentioned in the other thread are the goal not the method. I have the same goal. In both cases this is done by dragging and in both cases we noted that the ratio is not respected when there is no need for rounding. In the other thread’s case, 1500 x 1000 should be intrinsic to the 3:2 ratio, but it was giving 1500x999 or 1500x1001. It is understandable if the width is set to 1501 that the other dimension cannot be 1000.6 and so will round, logically, to 1001. But 1500x1000 is an exact multiple of the 3:2 ratio — no rounding required.
In my case, a 1:1 ratio is a common denominator for any size and so there is never a need to round pixels. To reiterate, if I drag a corner it is always exactly 1:1. It is only if I drag a side that the error occurs.
Yes it matters because my intent is a square shot, and while for some use cases a pixel or two may not matter, in others it will.
For instance, when I export I do so at full size, whereafter an automated script uses ImageMagick to add watermarks and resize the image to fixed dimensions. Sometimes I want to crop as closely as I can, so I set the crop to my goal dimensions, which the ImageMagick tool will address by not needlessly scaling the image. If it’s off by a couple of pixels, then I am going to get a scaled image that will introduce distortion as it is forced back to the intended ratio. Sure, 2 pixels in a few thousand won’t be noticeable, but there’s no need for it to be anything other than exact.
The workaround (at least for 1:1, I haven’t tested 3:2) is to finish with a corner drag to properly square up the figures. But often it is more convenient (and why else would PL offer the option?) to drag a side so that the other dimension stays centred on its current size.
In short, it does not always honour the ratio when the crop size (should be) a whole multiple of that ratio. That’s a bug, and my history tells me it’s a rounding bug. Possibly not enough precision in the calculation of the “other” dimension.