How about to cache listing of all resources that exist within mod-provided and vanilla resourcepacks by "identifier" that calculated from the pack(mod jar, file/dir, vanilla version)?
So that the cache will work through the instances instead of only a single run.

The idea is good in theory, and I have considered it. The problem is that computing that identifier in a safe manner requires hashing every resource contained in the resource pack. For zip/jar based resource packs, hashing the jar is fine, but not all resource packs are in that format, e.g. KubeJS. The time it takes to read all resources from disk and hash them defeats any savings that persisting the cache would bring.

In practice, computing the cached pack listing on each launch takes only a few seconds and is not the bottleneck to making launches faster.

(Also, this feature doesn't exist in 1.21, because NeoForge's FML is more efficient and I haven't seen enough profiling data to warrant reintroducing the cache.)

@embeddedt BTW. Is the mixin.perf.resourcepacks working in fabric?
I can't find any reference for PackResourcesCacheEngine in fabric module,
But the document saying all version supported.
Is it intended?

No, it hasn't been implemented on Fabric for a while. (1.19? 1.20? Forget which.)

What's the reason? Will you accept a PR for that?

If I recall correctly, it no longer significantly improved performance there. Also, I tend to focus on Forge launch performance at this point more than Fabric; there are far less large Fabric packs. I'd probably be unlikely to accept a PR as the cache engine can be finicky to implement without breaking edge cases in mods.

However, if I saw a profiler report showing resource pack file listing as a bottleneck on 1.21, I might reconsider.