A intenção é o inverso. Os branches de compatibilidade são apenas para branches ‘lançados’ do Discourse. O latest do Discourse sempre usará o main do seu plugin. É lá que você desenvolverá novos recursos.
Então, a história seria:
O Discourse lança o v2026.2. As ações do GitHub no seu plugin detectam isso automaticamente e criam um branch d-compat/v2026.2. Agora, qualquer pessoa que use o Discourse v2026.2 usará a versão d-compat/v2026.2 do seu plugin.
Você lança um novo recurso no main do seu plugin. Você não precisa se preocupar com compatibilidade retroativa, porque o branch main é usado apenas por pessoas que executam o Discourse latest.
Então, enquanto você bebe sua terceira taça de vinho 
, o Discourse lança o v2026.3. Inicialmente, não há branch de plugin para esta versão, então o main será usado. As coisas continuam funcionando como antes para as pessoas no latest.
Em poucas horas, sua ação do GitHub detecta a nova versão e congela o d-compat/v2026.3, pronto para que seu próximo recurso de plugin chegue ao main sem preocupações de compatibilidade retroativa.
Este é essencialmente o fluxo de trabalho que usamos na CDCK para lidar com a compatibilidade estável de temas/plugins. Após cada lançamento estável, temos um script para percorrer nossas centenas de temas/plugins e congelá-los via .discourse-compatibility. Esta proposta baseada em branches visa ser uma versão mais leve desse fluxo de trabalho.