Photos does a lot of extra work on import (merging RAW+JPEG pairs, generating previews, database indexing, optional deletion), so my guess is a concurrency bug where a buffer gets reused or a file handle is closed before the copy finishes.
Rare, nondeterministic corruption fits the profile.
What's the point of it? It is well known in the industry they ignore bugreports.
Also, this bug doesn't affect the majority of users, so it won't ever be fixed.
I'll tell you a secret though that kind of pisses me off. If you have shipped with a bug, that automatically lowers the perceived priority as well. You know, as opposed to introducing a new bug in a new release. "We've already lived with that old bug…" seems to be the mind set. Oh well.
To be sure though, if you saw the number of bugs that queue up for a popular app like Photos, you'd know that fixing all of them is not going to be possible — some kind of system of prioritization is required.
Why? If your app is used by billions of people, surely you can afford a few additional testers and engineers? Your app doesn't have an unlimited number of bugs: if you are solving them faster than you are introducing them, the number of bugs will eventually approach zero.
Sure, you'll always have newly-introduced bugs which are still waiting to get fixed, but if you've got an ever-increasing pile of bugs which have been around for years - even when they have been reported with easy-to-reproduce steps - then something has gone horribly wrong with your development process. At a certain point you have to stop shoveling new crap, rethink the workflow which is introducing so many new bugs, and slowly start fixing old bugs. The alternative is that your code will inevitably degrade into 100% bugs and become completely unusable and unmaintainable.
Unfortunately, in the real world, # of bugs solved per unit time does not scale linearly with # of developers - and, you eventually reach enough people that you can't effectively coordinate changes without wasting more time on processes than you're gaining by adding another person.
I've never worked at Apple and I don't know anyone on the Photos team, but I imagine a company at that scale probably has a good idea as to the optimal number of developers working on one application. Optimal to Apple probably involves optimal money spent:money earned ratio, not most bugs fixed per unit time, but I would wager those numbers are pretty similar anyways.