The Zip filesystem stuff is wonderful change to see: it takes a number of techniques that were common in the community (if you had the right tools and knew how to use them) for building standalone applications, and makes them part of the basic toolkit in a standard way. It's a truly excellent change, and I'm glad to see it.
It may be easier to reason about when thinking of the way $(mount -o loop) works with .iso files -- a file that is a container for other files that one can mount as if it were a filesystem
I was expecting pathlib in Python <https://docs.python.org/3/library/pathlib.html> to have one since a lot of Python distributions ship the standard library in .zip files but evidently not. Python gonna Python in that way
Firefox actually used to ship with that same "jar:" protocol handler, too, and I made good use of it for reading the javadoc html which was shipped inside zip files and was indescribably easier than trying to manage all the .html files in a Java 8 SDK distribution. They made heavy use of this because a lot of their internals were in .xpi formats (which is also a .zip file) but they recently dropped it because Firefox gonna Firefox^W double down on some random shit other than making a sane browser
The definition of "standalone application" is a bit stronger - what's always been possible with "Tclkits" has been to embed the application code in an interpreter binary and distribute that, and the new core zipfs supports that as well.
