Bien alors parlons technique du coup, parce que c'est encore plus probant. Et du coup, comme c'est un peu mon taf, penchons nous sur la question :p
Actuellement, l'idée est de fédérer une "techno" : shaarli (version sebsauvage qui n'est plus active et version community toujours en développement actif).
Blogotext est un outil développé par un développeur totalement différent, qui n'a aucune obligation de respecter "la ligne shaarli". Aujourd'hui, c'est le cas, certes, mais demain ? Que faudra-t-il faire ? Développer pour maintenir la compatibilité ou supprimer des dizaines ou centaines d'abonnements possibles ?
Et quid de l'apparition d'un outil qui serait "compatible" ? Faudrait-il l'intégrer aussi ? Et la question du dessus se reposera. À quel moment décide-t-on qu'un outil est compatible et doit être intégré ? Parce que le truc, c'est qu'à partir du moment où tu autorises Blogotext, il y a des critères qui font qu'il est accepté. Si un autre produit correspond à ces critères, il doit être intégré.
Une solution alternative serait de moduler tout ça. Je ne sais pas si c'est actuellement possible, mais l'idée serait la suivante, si on choisit d'ouvrir à autre chose que shaarli : tu veux être intégré ? Tu codes ton module et tu fais une pull request.
Ça a le mérite de répartir la charge de développement, d'avoir une gestion qui dépend de l'éditeur du produit à l'origine et d'être ouvert comme vous le souhaitez.
Quant au cas de Timo, c'est ce qu'on appelle du legacy, une "erreur de jeunesse". Il y a plusieurs moyens de gérer : supprimer, déclarer "exception jusqu'à ce que ça ne marche plus" ou "exception avec investissement". Dans tous les cas, le legacy ne permet pas de prendre en charge des éléments du même type (parce qu'argument fallacieux).