Can GIMP automatically disable plugins that fail to load after a version upgrade?

Short answer

No. GIMP has no mechanism that automatically disables a plugin after a failed load, and there is no per-plugin "disabled" state it persists between sessions. The behavior is simpler than it looks: at startup GIMP scans the plug-in directories, each binary is queried, and procedures that register successfully go into the procedural database (PDB). A binary that fails to load simply never registers. On the next launch GIMP tries again from scratch — it doesn't remember that the plugin failed last time.

What actually breaks after a major upgrade

Binary compatibility is not guaranteed across major releases. A plugin compiled against GIMP 2.10's libgimp generally must be rebuilt for GIMP 3.0, which uses a new plug-in API (libgimp-3.0) and a GTK3-based framework. So after a 2.10 → 3.0 upgrade, expect compiled third-party plugins to fail to load until their authors ship updated builds.

One consequence worth knowing: because a failed binary never registers, it usually leaves no broken menu entry — the menu item is just absent. If you see menu entries that exist but error when clicked, those almost always come from interpreted scripts (Script-Fu .scm or Python-Fu .py) that register fine but fail at run time. Scripts tend to survive upgrades better than binaries, though Python-Fu in GIMP 3.0 requires Python 3 and updated API calls.

Likely explanation vs. confirmed behavior

• Confirmed: load errors go to the console/error output; there is no compatibility checker, no rollback, and no documented hook or signal an external script could use to react to a load failure.
• Likely: a "safe mode that skips the plug-in folder after N consecutive failures" would be viable as a feature, but it does not exist today — you'd have to implement the quarantine yourself.

Practical recovery steps

1. See what's failing. Start GIMP from a terminal with verbose output and watch which plug-in binaries report errors during startup. Compare against the procedure browser (the PDB) to confirm which procedures actually registered.
2. Isolate with a clean profile. Override the GIMP user directory (e.g., a temporary GIMP3_DIRECTORY) to distinguish a plugin failure from corrupted user configuration.
3. Quarantine, don't delete. Move suspect binaries out of your user plug-ins folder (for GIMP 3.0, typically ~/.config/GIMP/3.0/plug-ins on Linux — paths differ by version and OS, so confirm against your install) into a separate quarantine directory. Relaunch; if GIMP starts clean, restore plugins one at a time to find the culprit.
4. Rebuild or replace. Obtain a build of the affected plugin compiled for GIMP 3.0, then confirm it registers and runs.

Caveats

Exact directory names, environment variables, and CLI flags differ between GIMP 2.10 and 3.0 and across operating systems — verify against your installed version rather than trusting any path verbatim. And compatibility ultimately depends on each plugin's build, not on GIMP alone, so the only reliable post-upgrade strategy is testing plugins individually.