Je comprends bien que c’est une démarche particulière ; mais prenons le problème à l’envers. En admettant que les PR se fassent sur master, compte tenu du nombre de commits sous-jacents au projet (plus d’une cinquante sur ma branche déjà à ce jour), ça risque d’être durs de faire le tri entre les fix et features de la release classique, et ceux qui sont surdéterminés par le nouveau paradigme des modules (enfin sauf si je reste le seul à travailler sur cette fonctionnalité 
).
C’est une histoire de compartimentation en fait. Idem pour les plugins-dist (comment faire le tri des commits au long cours et ceux qui reposent sur le nouveau paradigme importmap sans se perdre ?)
Ces branches temporaires doivent en effet se tenir à jour vis-à-vis de master, c’est un peu contraignant certes, mais il me semble plus favorable de concentrer la contrainte sur la branche dédiée, au profit d’une gestion plus simple sur master.
En outre, cette approche de branche dédiée ne serait que temporaire, le temps de gagner en maturité et avancer sur l’ensemble des plugins-dist avant de faire une fusion sur chaque branche principale.
Bon après si le projet trouve de l’engouement, et qu’on pense pouvoir l’intégrer de manière satisfaisante entre 4.3 et 5.0, alors peut-être, en effet, on peut rester focaliser sur master, mais il faut être conscient de ce que cela implique.
Je me range à l’avis des personnes en charge de la maintenance.
