Is the zip format standardized, or parsing of zips? Without looking I expect the former, because there are multiple ways to parse a zipfile: there's the infamous "does first or last entry for a given path count" problem (exacerbated by the distinction between "first in the directory in footer" and "first in byte order in the file itself").
Well, it's a spec for the format. It says things like "a valid ZIP file MUST ...", but doesn't specify the behaviour of the parser (can the parser assume that this holds? must the parser fail if it doesn't hold? what if it doesn't hold in a part of the file the parser wouldn't even ordinarily read? etc.).
Quick grepping through those appnotes doesn't reveal any expectations around path other than ones in 4.4.17, which don't specify anything about uniqueness (nor about interpretation of nonuniqueness, but that is not something I'd expect in a specification of format as opposed to parsing).
@robryk@qoto.org Then I don't know more than you do
BTW. https://github.com/google/wuffs/blob/main/doc/spec/rac-spec.md is an example of a spec that describes what a decoder must do, in a case where there are nontrivial constraints on it (that serve to make sure that you can't construct a compressed file that will decompress differently depending on whether you read from the beginning or not).
@robryk@qoto.org Lovely question, tell me if you find it in https://pkware.cachefly.net/webdocs/APPNOTE/APPNOTE-6.3.3.TXT