For the record, this new behaviour is wrong. It's not immediately obvious from the ZIP spec, but offsets have to be from the start of the file, not the archive, or ZIP64 can't work. And yes, that means you can't blindly concatenate ZIP files to other files, you have to rewrite them.

The way to create an 'embedded' ZIP archive like requested in issue #26293 is to write it to a separate file (or file-like object). Making "a" have this magical and wrong-for-almost-anyone meaning is... confusing, to say the least. The change certainly doesn't belong in a bugfix release, but I guess it's too late for that now. 

It's also not documented; the docs mention this:

  If mode is 'a' and file refers to an existing ZIP file, then
  additional files are added to it. If file does not refer to a ZIP
  file, then a new ZIP archive is appended to the file. This is
  meant for adding a ZIP archive to another file (such as
  python.exe).

which is ambiguous at best and certainly suggests the resulting file would be usable as-is, which is not the case if you use mode "a" (but *is* the case if you use mode "w", since 342bc734f523).