Though @rgchris has had other things in life to deal with the last couple of years, we talked tonight. We touched base on topics of whether the current isotope design meets with his approval--which is important as I consider him the Czar of Aesthetics. It sounds like he's given his seal of approval to the results. 
We also spoke about things of interest for him to come back to. This ZIP rethinking came up as being a notable example--of what he considers doing things in a better way than had sort of inadvertently become canon in the Redbol world.
So I wanted to bump this topic (and bring this to the attention of @bradrn), in terms of what it means to use a "context-based" approach vs. a "dialect-based" approach to a problem. It has more in common with COLLECT+KEEP than it does with the somewhat famous %rebzip.r, which had you build a "zip spec" which it would process:
you can zip a single file: zip %new-zip.zip %my-file a block of files: zip %new-zip.zip [%file-1.txt %file-2.exe] a block of data (binary!/string!) and files: zip %new-zip.zip [%my-file "my data"] a entire directory: zip/deep %new-zip.zip %my-directory/ from a url: zip %new-zip.zip ftp://192.168.1.10/my-file.txt any combinaison of these: zip/deep %new-zip.zip [ %readme.txt "An example" ftp://192.168.1.10/my-file.txt %my-directory ] [unarchiving: unzip] ! only works from REBOL/View, ! only understands methods 'store and 'deflate you can uncompress to a directory (created if inexistant): unzip %my-new-dir %my-zip-file.zip or a block: unzip my-block %my-zip-file.zip my-block == [%file-1.txt #{...} %file-2.exe #{...}]
(Another example of reimagining the old ways is his "PDF Backtrack")
Since Chris's time is limited, I'd like to focus on bringing whatever he considers to be the highest priority items to be ported to Ren-C and in continuous integration.
And this looks like something we might want to shift to using--instead of shipping with something like rebzip (which we currently use a derivation of).