Twine --skip-existing duplicate detection ambiguity

Twine's --skip-existing flag is documented to prevent re-uploading distribution files that share an identical name and version on the Python Package Index. However, the server-side determination of what constitutes a duplicate relies on a case-sensitive comparison of the filename and the upload timestamp, and the documentation does not explicitly state whether files with matching names but different timestamps are treated as distinct uploads. When --skip-existing is used, Twine reports a 409 Conflict response without clarifying whether the file was truly skipped or whether the server accepted a new upload with the same metadata. The behavior also differs between the production PyPI mirror and the Test PyPI instance, which may allow duplicate uploads for testing purposes. This ambiguity affects deployment workflows that depend on predictable overwrite semantics and raises whether Twine should emit a standardized warning when a duplicate is detected on the server, regardless of the flag's presence.

What criteria does the PyPI server use to identify a duplicate distribution file when --skip-existing is omitted? Should Twine emit a standardized warning when a duplicate is detected on the server, regardless of the flag? How should deployment pipelines distinguish between a server-rejected upload and a silently skipped one when using --skip-existing?