Miscellaneous brainstorming:
Dumb terminal version: Usually these just omit any text that would be printed to the upper window, with predictable results. My advocacy here is mainly based on the idea that any z-machine is better than none (and also perhaps by my own quixotic delight at getting z-machines running on just about every imaginable machine, Doom-on-a-toaster-style). But in my experience relatively few z-code games actually require the status line in game-breaking ways; certainly most of Infocom’s z3 games don’t, and even Curses! (which uses a custom multi-line statusbar, help menus, and boxed quotations) is perfectly winnable without them as long as you know what you’re getting into. This is why dumb-terminal implementations like the xyzzy discord bot generally work.
Disk switching: This one’s weirder but if you do want to go down this route, I think there are probably two comparatively easy ways to do this. This is applicable to any CP/M system with SS/SD or SS/DD 5.25" drives (a lot of them: Osborne 1, Apple II, Kaypro II, earlier Amstrad CPCs and PCWs, Xerox 820, etc.), but I’ll use the Apple II as an example since that’s the platform I am most familiar with. Apple II double-density disks have a nominal capacity of 140kb but are practically limited to about 127kb when formatted for CP/M.
Two methods:
1 - quasi-Infocom method (thanks @fredrik): read a portion of the game into memory, prompt for Disk 2, and then do any necessary disk access on that one disk. The Infocom terps on the Apple II require 128kb of RAM to do this and do some funky business with track interleaving to pack more than 140kb of data onto Disk 2, which allows them to run story files up to 256kb. An easier method might be to just read 32kb of dynamic and static memory, prompt for Disk 2, and then read from disk as usual with an offset of -32kb, permitting story files up to 32kb + 127kb = 159kb.
2 - dual-disk setup: load the story file as usual, but read all data after (say) 112kb from a second file handle pointing to drive B:. This would require two drives (pretty standard on machines of this era), but would let you run games up to ~239kb (or ~254kb if you loaded the terp from drive B: and then swapped out the disk).
How helpful would this actually be? Because I’m a scientist and I like data, I pulled a few rough statistics. The games/zcode folder of ifarchive contains about 250 files that are <128kb and about another 250 files that are 128kb-256kb. Of course, the smaller files disproportionately include minigames and low-effort experiments. For a more realistic sample of what I would want to play, my personal folder of classic z-code games contains about 50 games that are <128kb (of which 23 are Infocom) and about another 80 that are 128kb-256kb. Many of my favorite z-code games - such as Savoir-Faire and The Mulldoon Legacy - are >256kb, but these mostly require too much dynamic memory to run anyway. Still, the 128-256kb range contains some great classics that should work, such as Spider and Web, Christminster, Metamorphoses, Curses, Winter Wonderland, All Roads, Ad Verbum, etc.
The number of classic games which would benefit from the first 159kb disk scheme is relatively small, but there are some (e.g., Ad Verbum, The Moonlit Tower, The Weapon, Janitor, Insight, Final Selection, All Things Devours). The bigger advantage would be the ability to run 128kb Infocom games from a single disk drive - although if you like to live dangerously, you can already do this by quickly hot-swapping the disk after Vezza loads but before it begins reading the story file. (I can confirm that this does, technically, work.)
