A realidade aqui é que a branch estável é um LTS, e um muito bom. Ela recebe atualizações de segurança e é bem claro quais versões de plugins são compatíveis com ela (graças ao arquivo .discourse-compatibility). Admito totalmente que demorou muito para que tudo isso funcionasse, mas nos últimos dois anos, funcionou – o que é uma grande conquista da equipe.
Agora para a segunda parte da sua declaração. É de fato o caso que stable é frequentemente representado como algo que você não deveria querer. Mas na hospedagem Communiteq, oferecemos aos clientes a escolha gratuita entre stable (“estabilidade primeiro, novas atualizações duas vezes por ano, atualizações de segurança uma vez por mês”) e tests-passed (“sempre na vanguarda, novos recursos uma vez por mês”) nos últimos 2,5 anos e 85% escolhe ficar no stable.
Eu entendo isso. Mas isso não é um problema de desenvolvimento e não um problema de produção? Posso entender totalmente que você está fazendo isso em desenvolvimento. Mas adicionar esses plugins em uma instalação de produção padrão meio que anula a ideia de ter um plugin (que é algo não padrão por definição).
A única vantagem real de produção que vejo é a questão muito, muito específica de desinstalar plugins e hosts multisite. (Novamente, isso é uma coisa boa, todas as outras questões de produção foram resolvidas ao longo do tempo!)
Isso também poderia ter sido resolvido no script de configuração mostrando uma lista de plugins que os usuários podem marcar e, em seguida, adicioná-los ao app.yml.
Mas você ainda oferece conjuntos diferentes (subconjuntos) de plugins para diferentes níveis, certo?