I can think of two possible "root causes" with this vulnerability.

One is where the API ("2nd step" mentioned in the doc, POST with a desired email address to get a JWT) is an authenticated API, meaning it requires a valid credential, but Apple's implementation of this API made a mistake of not checking if the user-requested email belongs to the user or not. In this case, the log can give enough information for the forensic analysis to determine misuse. I presumed this was the case.

The other possibility is if they implemented that API as unauthenticated. I presumed this was not the case - as this is a more difficult mistake to make, and given that they claimed some knowledge of no misuse - but I have no way to know for sure this isn't the case here. The end result would be the same. If the root cause was this case, indeed it's difficult to know if no misuse has happened.

Assume they have two log entries.

  request 678: request from user bananas
  request 678: issued token for bananas

That looks good.

  request 987: request from user <blank>
  request 987: issues token for carrots

That doesn't look good.

They very like have a complete log of the action performed; I'd guess, they'd perform some kind of replay/playback after the bug was fixed, and see what failed to pass. Assuming their changes immediately flag things like the researcher's initial attempts and discovery, it'd probably be pretty safe to say that no one was affected if no other instances are flagged.

How does that answer the question? So what if you can replay logs of all attempts? How can you prove for any specific log that it was the “real” user making the request, and not someone using their email maliciously to make an identical request?

It doesn't. That's also the downside of most login/identity providers that implement some form of "Impersonation."

Without really smart and well-considered limitations and logging, it's impossible to tell the User from the User* without digging through audit trails, etc.. and if the developers/architects involved didn't consider the limitations and logging in the first place, odds are they didn't consider the audit trails either.

And yes, I do this for a living.. and have seen bad things from major organizations. :(

They are the issuer. it's trivial.