Sur le fond, comme tu l’as dit, le cycle de vie des plugins-dist est indépendant de celui de SPIP.
Et donc, oui une branche de plugin-dist peut couvrir plusieurs branches de SPIP, comme, au final, tous les plugins non-dist peuvent le faire. Voir Ce petit doc qu’il faut que je pense à mettre à jour régulièrement.
Indépendant donc, mais jusqu’à un certain point seulement. En effet, les plugins-dist sont taggués (et donc, releasés) en même temps que SPIP, le même jour. Donc, c’est un cycle de vie distinct en terme de numérotation, mais pas en terme de release. Autrement dit, c’est pas si indépendant que ça.
De plus, pour les phases de dev ou de maintenance de spip/spip, on intègre les plugins part branche de dev ou de maintenance de plugin. Ce qui, dans l’absolu pourrait ne pas être nécessaire. Mais c’est un autre sujet.
D’autre part, il y a encore des interdépendances entre le code des plugins et celui de spip/spip. Ce n’est pas une bonne chose qu’un plugin dépende d’une ou plusieurs fonctions, de constantes, déclarées dans spip/spip mais aussi, parfois, du code dans spip/spip qui appellent quelque chose qui est déclaré dans ce plugin. ça rend ces portions de code « fortement couplées » comme on dit dans le jargon. Quand 2 versions de spip/spip dépendent (via composer.json ou plugins-dist.json) d’une même version d’un plugin-dist alors qu’on veut faire évoluer spip entre ces deux versions… ça devient très complexe … et on se retrouve avec du code qui ressemble à ce qu’on a aujourd’hui : plein d’exceptions (ou de tests comme tu en proposes) ou bien des bugs ou bien des mauvais signaux dans nos IDE, etc. 
C’est entre autre pour cela qu’on propose, au moins @marcimat, @b_b et moi-même de déplacer des portions de code de spip/spip, en particulier du dossier ecrire/ dans autre chose … mais c’est difficile. Un peu techniquement, beaucoup humainement. Mais bon, peu importe. La situation à ce jour nous oblige à faire le grand écart avec des versions communes entre dépendances.
(tout cela est très schématisé…)
Bref, aujourd’hui, on a pas trop le choix, hélas. Les tests de présence que tu proposes me semblent inévitables en attendant qu’on fasse mieux (du « découplage » de code).