I've hit this recently too, the problem occurs during the upload process.
Using the crop names in the original report, the three images result in the same file name. During resize newscentered is saved, it's then replaced by the newstop crop which is in turn replaced by the newsbottom crop.
While site owners don't get the crops they expect, a side-effect is the srcset for an image may contain different crop orientations.
I suggest files be saved with an eight character hash of the crop information returned by image_resize_dimensions() to ensure neither of these problems occur. The file name could be uploaded-name-c{$hash}.ext.
image_resize_dimensions()'s return array is:
<?php
$dims = [
0 => 0
1 => 0
2 => // Crop start X axis
3 => // Crop start Y axis
4 => // New width
5 => // New height
6 => // Crop width on source image
7 => // Crop height on source image
];
The crop hash could be generated from $source_w,$source_h,$dims[2],$dims[3],$dims[6],$dims[7]. This will ensure images from the same source with the same aspect ratio and crop will end up with the same hash.
If the final two values are the same as the source image then no hash is required.
When generating the srcset in wp_calculate_image_srcset() the crop hash can be checked in the same way as that the edit suffix is checked.
In terms of backward compatibility I don't think there are implications as previously uploaded images will not have a crop hash.
cc @joemcgill as we've discussed this previously.