The process of rolling back features from WordPress Core isn’t entirely uncharted territory. Look at examples like the Classic Editor or the Link Manager. Interestingly, these weren’t fully removed—they merely introduced feature flags through plugins. This highlights the need for a structured method to properly extract features while ensuring backward compatibility.

I can imagine working with two concepts WordPress already employs: Bundled Plugins (like Akismet) and Required Plugins. The process could unfold in three phases:

1) Plugin Rollout
Initially, the feature is extracted into a dedicated plugin, which comes bundled with new WordPress releases. During this phase, the plugin is a required plugin, meaning it’s activated by default on all installations to ensure continuity.

2) Feature Flag
Once the plugin achieves broad adoption, the “required” status is removed. WordPress still bundles the plugin, but users gain the ability to deactivate it. Core would use a feature flag to detect if the plugin is active, ensuring that sites without the plugin don’t load the feature. Importantly, the underlying code still resides in Core for now, preventing site-breaking changes.

3) Code Extraction
After sufficient testing and adoption, the feature’s code can be safely migrated out of Core and fully into the plugin. This phase would likely involve a grace period where the code exists in both places, similar to how Gutenberg is still handled today.

By the end of the third phase, all pre-existing installations retain access to the feature through the plugin. Meanwhile, new users have the choice to opt-in or out. This method ensures minimal disruption, respects backward compatibility, and offers a clear path forward for decoupling features from Core.