The intention is the reverse. The compat branches are only for ‘released’ branches of Discourse. Discourse latest will always use main of your plugin. That’s where you’ll develop new features.
So the story would be:
Discourse releases v2026.2. GitHub actions on your plugin automatically detects this and cuts a d-compat/v2026.2 branch. Now, anyone using Discourse v2026.2 will be using the d-compat/v2026.2 version of your plugin.
You release a new feature on main of your plugin. You don’t need to think about backwards-compatibility, because the main branch is only used by people running Discourse latest.
Then, while you’re sipping your third glass of wine 
, Discourse cuts v2026.3. Initially there is no plugin branch for this version, so main will be used. Stuff keeps working as it did for people on latest.
Within hours, your github action detects the new version and freezes d-compat/v2026.3, ready for your next plugin feature to land on main with no backwards-compatibility concerns.
This is essentially the workflow we use at CDCK to handle stable compatibility of themes/plugins. After each stable release, we have a script to run through our hundreds of themes/plugins and freeze them via .discourse-compatibility. This branch-based proposal aims to be a lighter-weight version of that workflow.