What's the .meta file?

With timestamp, do you mean the file timestamp, or the timestamp(s) written in the index ("Log List") file? Can you give an example of how the deletion could be done on one but not the other?

For posterity:
* The .meta files were explained here: https://chromium-review.googlesource.com/c/chromium/src/+/982055/4/components/webrtc_logging/browser/log_cleanup.cc#90
* Wrt the numbering set by the first message on this thread, #1 is the timestamp recorded in the .csv file. #2 and #3 are the last-modification dates of the files themselves.
* An example of deletion of one item but not the other - the user has the power to navigate his own filesystem and remove any files he wishes. Or edit them. Or create thewm.
* Additional examples include write errors, media being yanked-out during writing, files not being deleted because some other software running in the background and scanning files having a handle to them, etc.

Sorry, there was also a small mismatch between my original bug description, your question's phrasing, and my answer. There are several issues around this. Among them:
1. One entry being deleted, another being left behind.
2. What happens "next time" after such a case was created.

I was focused in my last message on #2, but maybe you're more interested in #1. The answer there is - things don't happen concurrently. When two files are created, they can get a slightly different timestamp. When the index file (.csv file) is written, it gets timestamps that furthermore might not correspond to both (or either) of those timestamps. So you have up to three potential different timestamps. It could be that one is past expiry, and the others aren't.

Re question "do you mean the file timestamp, or the timestamp(s) written in the index" (in comment #1): thanks for clarifying, I hadn't notice the "in" and "of" in the original report when I asked.

Re question "Can you give an example of how the deletion could be done on one but not the other?" (in comment #1): I meant when the timestamp mismatch can cause a delete mismatch in our algorithm (not external modifications), which I think you answered in comment #3 - the expiry can cause this. My recollection was that we don't delete them independent of each other but maybe we do.

OK, I have all info needed for now. Thanks.

"My recollection was that we don't delete them independent of each other but maybe we do."
Actually, we don't. But I think we should, because otherwise, if a user ever manually deletes a file, that file would never be purged from the index - and that's a problem.

If that's the case now, that's obviously not good.

Indeed.
Please note the following TODO:
  // TODO(crbug.com/826254): Purge index file separately, too, to ensure
  // entries for logs whose files were manually removed, are also subject
  // to expiry and browsing data clearing.
It was introduced by this CL:https://chromium-review.googlesource.com/c/chromium/src/+/982055/

I've now also assigned the relevant bug to you.