Your setup, at home in Torbie.

A tortoiseshell tabby: the lineage is in the name, and the product is its own. Everything a user or the operating system reads is renamed; nothing a plugin reads is. There is no version gate anywhere in the loader — the tabby- package prefix and the tabby-plugin npm keyword are the entire compatibility contract — so touching either would silently unload everybody's plugins. Four places recognised a build by the literal 'tabby' and each was half of a pair that breaks in silence: rename one side and the scan just finds nothing, or the health check calls every stuck build healthy. They read one shared list now, which keeps both products, because an installed Tabby is still a build this machine has. The profile is copied forward before anything reads it, both environment prefixes are honoured, and tabby:// stays registered beside torbie://.

The fork had diverged far enough to stop being "a patched Tabby" — 100-odd commits, its own diagnostics, watchdog, resume and build-slot subsystems — while still calling itself by upstream's name, reporting into upstream's accounts, and writing into upstream's config directory. That is confusing for a user and unfair to upstream.

Everything a user or the operating system reads is renamed: product name, window and tray titles, splash, installer artifacts, shell integration, Start-menu and slot shortcuts, the appId. Nothing a plugin reads is renamed, and that asymmetry is the whole design.

• The plugin contract is untouched, because there is no version gate to fall back on. The tabby- package prefix, the tabby-plugin and tabby-builtin-plugin npm keywords and the module names plugins require are the entire compatibility check — there is no apiVersion anywhere in the loader. Renaming either half would unload every installed plugin with no error at all. Verified live: all 17 load, and the diagnostics log records no require-failed beyond the one that is expected on Windows.
• Four pairs that break in silence. A build was recognised by the literal 'tabby' in four unrelated places — the install roots, the executable beside resources, a checkout's package.json, and the window title that means a renderer never booted. Rename one side of any of them and nothing throws: the scan finds nothing, or the doctor calls every stuck build healthy. They read one shared list now, and it keeps both products, because this machine still has an installed Tabby and a page whose job is "every build here" must go on seeing it.
• The profile is copied forward, never moved. app/package.json's name decides userData, so it moved; the old profile is copied in before anything reads the config directory — config, window geometry, credentials, jump-list icons, plugins, and Local Storage, which holds the saved tab layout and is the one whose loss would be destructive rather than merely rude. Copy rather than move, because the old directory belongs to an app that may still be running.
• Both environment prefixes are honoured and neither is retired. TABBY_* is documented, used by every test here, and already sitting in shell profiles and shortcuts — where an unset variable is not an error but a default. Each is mirrored to the other once at startup, so a caller may use either. tabby:// stays registered beside torbie:// for the same reason.
• This codebase has done this once before: it still migrates ../terminus/config.yaml forward and still aliases tabby-* to terminus-*. That rename is the template, and its lesson is add names alongside, never replace.

• The icon is still Tabby's. The mark belongs to a brand-asset skill that owns the locked geometry and asset-sync graph, and hand-editing mark assets is exactly what that skill exists to prevent. The interface has not been moved onto the studio's palette either.
• The macOS Automator workflows are unverified. They were renamed and their now-meaningless code signatures dropped, from Windows, with no way to test them. They previously launched Tabby.app/Contents/MacOS/tabby, so leaving them alone was a certain failure rather than an unverified one — but that is a trade, not a fix.
• Thirteen translated strings changed their msgid and now fall back to English in all 23 locales. Regenerating the catalogue needs gettext's msgcat, which is not on the machine this was done on.
• Changing the appId changes the AppUserModelID, so an existing taskbar pin carries the old identity and an NSIS upgrade becomes a side-by-side install rather than an in-place one.