What if I need an ID in the filename and I get the date sorting for free?

You know, like described in the OP.

Is it okay if thats useful?

Yes. I agree with the sentiment that UUIDv7 being chronological can be useful. But, in this specific example, I think it’s a design smell to design your feature around the format of the filename and UUID generation algortihm. I’d say, wait for the FS if you have to instead of creating failure-prone dependencies like that.

What part is failure prone?

What is it being relied upon for?

Alternatively, more explicitly, lets look at it from this angle:

Let's follow exactly what you're recommending: parse it from the file.

Then add a fault-tolerant layer in front that parses a UUID-v7 from the filename.

What do you think of that?

The assumption that the app files would always use the same format and the same UUID algorithm in that format is a totally unnecessary tight coupling for a “loading UI”. The potential future costs isn’t worth it.

Adding layers, etc. Again, it’s a loading UI.

Obviously, we’re talking about a fantasy app here. I’m weighing options based on my understanding of it.

Gotcha, a better name for it is fantasy app.

Let's have the fantasy app do exactly as you're recommending.

Now, the fantasy app also happens to store its file using this filename format: {uuid}.json

What objections are there to parsing the uuid from the filename and using it to sort?

Assuming you again mention the filename not be a valid UUID:

Is it possible to account for that and fallback to the safe behavior? :)

No, because you wouldn’t know if UUID algorithm was changed. It’s a completely unnecessary coupling, like tying your shoelaces together before running.

Reductio ad absurdum: same argument applies to any persisted UUID.

Do you understand? On second read, could be too short and unnecessarily Latin-y. :)