Je me reposais la question à l’instant et je remarque qu’on ne l’a toujours pas ajouté à https://plugins.spip.net/redaction-du-paquet-xml.html :d
/{prefixe}-xx.svg me semble d’autant plus pertinent que ça permet de récupérer tels quels les logos SVG des plugins existants qui sont, en général, de la forme .../prive/themes/spip/images/{prefixe}-xx.svg
Exact on a toujours pas adopté réellement cette logique ni on l’a décrite quelque part.
Par contre, on avait plus ou moins entériné que le logo serait à la racine avec un nom qui coïncide avec le préfixe du plugin, soit prefixe.svg.
Ca parait assez logique car le logo n’est pas destiné à être réutilisé autrement qu’en logo.
En cela je répond à @cy_altern car si un plugin décrit un objet patate et même si le préfixe est patate, je pense qu’il faut créer un icone patate-xx.svg dans les thèmes d’images qui soit clairement séparé : qu’il reprenne le look & feel du logo n’est pas une raison pour le réutiliser à partir de la racine.
L’idée initiale est bien de séparer les thèmes d’icones et le logo.
Oui mais à partir du moment où un plugin est compatible SPIP 3 et SPIP 4, il faut fournir son logo dans les 2 formats patate-64.png et patate-xx.svg (même si on est à la racine). Car si on mets seulement un patate.svg le logo sera cassé en SPIP 3
Oui exact, c’est encore le cas pour ceux qui traversent spip 3 et 4.
Ca milite peut-être pour appliquer systématiquement cette règle que pour les plugins uniquement spip 4.
Par contre, la séparation logo et thèmes peut elle être appliquée indépendamment du nommage du logo.
Et en spip 5 on essayera de se débarrasser des cas spip 3 
Perso je parlais uniquement des plugins compatibles SPIP 4, SPIP3.2 est en fin de support, et je suis d’accord avec @eric_tonton un plugin maintenu et compatible SPIP 4 devrait avoir une branche dédiée.
Moui enfin j’ai un peu de mal avec les ayatollahs des branches. C’est parfois très pertinent de brancher, parfois pas du tout.
Par exemple sur le plugin bank qui est et sera encore utilisé sur des versions SPIP 3.x pendant un bout de temps, ce serait bien plus couteux et risqué pour moi de maintenir 2 branches pour 2 versions de SPIP, avec du coup le besoin de tester tout en double. Il est beaucoup plus safe d’avoir une seule version qui tourne partout et d’y fixer les bugs et évolutions d’API que de gérer des divergences entre branches…
Donc ce « devrait » me parait être un peu trop directif si je puis me permettre et ne pas vraiment prendre en compte les diverses réalités du terrain et de chaque plugin…
Bref donc je pense que c’est bien qu’on ait une convention idéale pour les plugins 4+ c’est parfait, et une solution propre pour les plugins 3.2+ même si elle est moins idéale.
1 « J'aime »
Les branches c’est bien, mangez-en, na 
Tout à fait 