It can be a very subjective thing, so if we are going to do it, we'd need to decide exactly how to do so.

While I agree with you in theory, I'm not sure its possible to create one rule for all. How the build date is found should be done thoughtfully and documented properly, but I don't think the same method can be used on all discs.

What do you mean? I think having a version identifier instead of an arbitrary number is preferable to most people. And "Beta 1" vs "v1.00" or "2020-01-01" don't differ wildly in length.

I do like the idea conceptually of adding valuable data that is helpful in identifying different discs.  For example, I strongly prefer the way we handle datnames for PS2, versus PS1.  PS1 is standardized "Demo 1" "Demo 2" "Demo 3" and the numbers can change back and forth depending on dates and such.  So what is Demo 1 now may change to Demo 2 later, etc.

This is all a compromise of keeping things under control, while adding enough detail to distinguish releases.  The challenge is, different people use dats differently and have different preferences about what information they want to see in filenames.

PVD often stays the same even when internal files are updated across versions.

IMO best way would be to detect the dates of all files on the disc and go with the latest date of all files.

That'd make more sense, although there are likely instances where that isn't accurate, and a game-specific build date string in the data, or text written on the disc label/case is more accurate. I think really its a per-game thing, but the reasoning could be put in the comments to make it clear.

IMO best way would be to detect the dates of all files on the disc and go with the latest date of all files.

Using both a "Rerelease" tag and date tag would be a lot of extra filename length added to indicate mostly the same thing... Maybe an abbreviation for rerelease could be used? On Discogs they use a quick "RE" or "Re" tag to indicate this.

[Edit: Nvm, misread. "Rerelease" handling is already established... Not sure how you might abbreviate "beta."]

To be clear, my proposal was:
Game Name (Region) (Languages) ---- retail, as usual
Game Name (Region) (Languages) (Beta) ----- if there's only one beta disc
Game Name (Region) (Languages) (Beta) (PVD 1) and (PVD 2) ----- two beta discs with two different PVDs
Game Name (Region) (Languages) (Beta) and (Beta) (Alt) ------- two beta discs with the same data track but different audio tracks
Game Name (Region) (Languages) (Beta Disc Title 1) and (Beta Disc Title 2) ------ another idea is to use the complete title when the discs have two different specific titles, like Alpha Version v1.01 and Beta Version v1.15, or whatever stuff it's written on the discs.

[Edit: Nvm, misread. "Rerelease" handling is already established... Not sure how you might, or if you would even want to, abbreviate "beta."]

And to take this discussion to another level, we're doing the same for some system demos, where it's Demo 1 or Demo 2 for PS1, when we're doing a different thing on PS2 demos, calling them Demo, Trade Demo, Taikenban, Tentou-you Taikenban, etc. based on the specific name.
IF we ever decide to not use Beta 1, 2, 3 names we should to the same for the PS1 demos, if that makes sense for you guys.

The date used may have to vary by system, as some systems don't have an easily identifiable executable, and some systems don't have a PVD. The date on labels can be wildly off from the actual content date as well.

Yeah its a per-system or even per-game thing.

That could work, although I think there should be dashes, otherwise its pretty unreadable.

Right now the system is to put the earliest known Beta as (Beta 1) and later ones as (Beta 2) (Beta 3) etc in chronological order.

In my opinion, I would keep the Beta numbering but add an additional tag at the end for date, similar to the (Rerelease) (19990101) system used for IBM PC (We do not use dashes here).