What problem are we trying to solve?
I think it's reasonable to request that DotNetZip classes be modified to be thread safe. It's reasonable to ask, but unreasonable to expect that I will do the work. Most use of DNZ is single-threaded, and changes to support multiple threads would be
far-reaching and not performance neutral. I don't feel like there's a good payback there, so I wouldn't do that work. Also, the workaround is simple: open multiple instances of the ZipFile.
On the other hand I'm not sure what you're asking for here. What problem are you trying to solve?
based on my understanding, ZipEntry.OpenReaderOnOwnStream() would be a half-way step to multi-thread support. IT would be multi-thread support, but only for reading entries. The special-case nature of it seems sort of inelegant, from the start.
Secondly, It's not so easy to build this. Opening a reader is simple. But once such a reading stream is dispensed, the zipfile could not be updated at all, if there were any outstanding "other thread" readers. The library
would need a mechanism to release that lock. This makes the API considerably more complicated to support the scenario of multiple threads. The internal implementation is much more complicated. All of this is hard to get right, hard to maintain, and hard
to explain to the large majority of users who just don't care about 2nd-thread readers.
To me, you identified the base issue in your original question: The filestream pointer. In fact the situation with a ZipFile is exactly analogous to the situation with the FileStream type. It's a fairly simple object. and it is not thread
safe. To read or write a file from multiple threads, you must open multiple FileStream instances. The same applies to a zip file.