La mauvaise foi est de s'appuyer sur des chiffres quand ça vous arrange, et de nier l'intérêt de certains chiffres quand ils vous dérangent.
Je ne sais pas si on s'est mal compris, mais en relisant mon premier message ça me parait toujours clair : à aucun moment je n'ai dit "beaucoup de plugins / beaucoup de sites utilisent Bonux et donc il faut l'intégrer au noyau".
J'ai dit très exactement que *ceux* des plugins qui utilisent Bonux, le font tous pour avoir accès aux boucles POUR et CONDITION. Juste pour dire que Bonux, qui est au départ un agglomérat de choses qui auraient pu être dans SPIP 2.0 mais qui n'étaient pas au point au bon moment, est essentiellement utilisé pour ces deux fonctionnalités. Ma réflexion partant du fait que je vois de plus en plus de plugins le nécessiter alors que ces boucles ajoutent des choses que je trouve basiques lorsqu'on programme (je reviens sur ce mot plus loin).
Alors pourquoi as-tu commencé par parler chiffres ?
Cf la phrase commençant par "Juste", précédemment.
Un "noyau" n'est pas un "ensemble", c'est un organisme cohérent.
Au sens strict oui. Mais le noyau de SPIP, même sans parler des objets éditoriaux, reste un ensemble : un compilateur de squelette, un API de serveur SQL virtualisé, une API d'autorisations, une API pour faire des formulaires, un agglomérat de fonctions "utils", une API pour générer des URLs différentes, etc.
Moi j'entends "noyau" comme "une base simple à comprendre et solide sur laquelle greffer des extensions".
Oui, on peut toujours trouver un noyau plus petit, plus pur.
Boucler sur autre chose qu'une table introduit une incohérence, et augmente le temps d'apprentissage du noyau. On ne peut plus dire "le langage des squelettes s'apprend très vite".
Pourquoi une incohérence ? Par rapport à ton système de valeurs ? 
Si tu penses que le centre du centre du centre de SPIP ne devrait être qu'un langage permettant de lire une base de données et d'afficher ses champs, effectivement.
Mais puisque tu aimes expliquer le sens des mots, je veux bien apprendre (vu que je ne connais pas les grands concepts de théorie du langage qu'il y a derrière ) : en quoi le mot "boucler" indique que l'on boucle sur une table de base de données ?
En quoi boucler sur une table est différent de boucler sur le contenu d'un tableau (surtout que par derrière, le contenu de la table est d'abord transformé en tableau) ? Pour l'instant, pour moi, le terme "boucler" ou "faire une boucle" veut dire : *parcourir un à un une liste d'élément*. Et ça tombe bien : c'est ce même sens qu'utilise la plupart des autres "langages" (entre guillemet parce que je ne parle pas que des langages de programmation, mais aussi tous les simples langages ou syntaxes de templates, qui proposent tous un moyen de boucler sur un tableau).
Si on invente un sens à "boucler" qui est uniquement propre à SPIP, c'est justement là qu'on ne peut pas dire que c'est facile à apprendre.
Moi ça me paraissait évident
Chaque fois que qq parle d'évidence, la seule évidence qu'il prouve est qu'il refuse de considérer que les autres peuvent avoir des référents culturels différents des siens. Les politiciens adorent cette réthorique qui permet de faire croire que leur volonté n'a pas à être débatue.
Et inversement, ne jamais trouver qu'il y a des choses communes à *tous*, ouvre la porte à un déconstructionnisme permanent. 
mais justement le langage des squelettes n'est pas un langage de programmation, et si on franchit cette ligne jaune, il doit alors se comparer à d'autres langages de programmation, notamment PHP, et alors SPIP est perdant car lacunaire et incohérent.
Ça ne me viendrait pas à l'idée de faire de SPIP un vrai langage de programmation. Il n'en a jamais été question je crois.
Au départ le langage des squelettes est un langage de ... squelettes. De template quoi. Ce qui n'indique toujours pas qu'il ne doit afficher que des choses venant d'une base de données !...
C'est pas tout blanc ou tout noir, soit un langage de programmation complet et cohérent, soit un langage qui ne fait qu'aider à afficher une base de données...
Tous les langages de templates permettent de faire des conditions et de boucler sur des liste d'éléments. (Non le "tous" n'est pas dit à la louche : Web template system - Wikipedia .)
C'est bien dommage.
C'est pas très pédagogue comme réponse.
C'est à ceux qui pensent que ces constructions foireuses sont viables de le faire, pas à moi.
Expliquer comme résoudre, c'est aux autres oui. Mais expliquer ce qui est foireux, c'est à ceux qui trouvent que c'est foireux, non ?
Bon alors Cédric ? 
Et sinon dans un premier temps, est-il imaginable de :
- améliorer l'implémentation puisqu'il parait que c'est foireux
- en faire une extension du core pour justement ne pas le mettre dans le noyau mais qu'il soit dans la distribution de base quand même ?