Wir drehen uns im Kreis, aber das hast du sicher auch gemerkt. Ich habe dir für einige der Punkte die du nennst doch schon antworten geliefet (z.B. Frameworks). Vor allem aber haben wir verschiedene Vorstellungen davon wann ein solcher Pattern beginnt relevant zu sein, und wann nicht, oder wann es einfach zu wenig ist um dafüt zu gelten.
Ich überspringe mal salopp deine Einzelfragen, weil wir uns sonst wirklich in der Tiefe verlieren, und das ist weder spannend noch nützlich.

CoC ist ein Pattern der sehr viel meinen kann, oder sehr wenig. Die üblichen Beispiele sind oft sehr tiefgreifend. Ich halte diese aber auch für die Beispiele, welche die größte Relevanz habe (ich komme gleich nocheinmal darauf zurück).
Natürlich gibt es Beispiele wie JUnit, bei dem ein test* bereits als CoC gilt. Das ist auch durchaus berechtigt. Allerdings ist es auch dort nur ein kleiner Teil davon, und deswegen ist es kein wesentlicher Aspekt davon.

Gehen wir kurz zum Anfang der Diskussion:
"Bei "Convention over Configuration" wird viel implizit angenommen", und vorher hattest du Django genannt.

Ein Teil unserer Diskussion bassiert sicherlich auf meiner Aussaage "Django folgt "Convention over Configuration" nicht. ". Diese Aussage bezog sich eigentlich nicht darauf das es keinerlei Aspekte gibt die CoC entsprechen, aber auch das Django sich CoC nicht verpflichtet fühlt, und praktisch keinem der üblichen CoC Fälle folgt. Dazu habe ich Beispiele genannt.

Am Ende muss man sich darüber einigen, folgt etwas CoC wenn es das als Kern nimmt, so wie Django dem Ziel "loose coupling and tight cohesion", oder wenn es das nur irgendwo in etwa nutzt.

Da es Frameworks gibt die sich CoC auf die Fahne geschrieben haben, finde ich das wir bei solchen Aussagen es streng nehmen sollten. Junit wird nicht als CoC bezeichnet, und Djando auch nicht. Einfach weil beide nur das Tun was man in dieser Richtung schon immer tat. Das, was heute mit CoC gemeint ist, geht aber darüber hinaus. Das siehst du anders, das ist für mich auch ok, aber die meisten CoC Frameworks die mir begegnet sind haben Aspekte in ihrem Design (wie dem URL Mapping, dem ORM) denen Django nicht folgt.
Du sagst das einfaches Verhalten wie "User" Model zu "user" Tabelle sei CoC, ich sage das ist einfaches Mapping. Das hat man immer so getan.
Natürlich gab es Frameworks/Systeme die wirklich wirklich schlimm waren, und jeden Furz in einer Konfig brauchten. Aber das war auch zu dem Zeitpunkt schon ein Extrem. Nur weil man nicht dem einen Extrem folgt, ist man doch nicht automatisch im anderen. Das sehe ich einfach anders.

Also wirklich nur zum Klarstellen: Ich bin der Meinung das Django CoC nicht folgt, weil ich der Meinung bin das dies ein bei Frameworks benutzer Begriff ist für ein Prinzip das man im ganzen folgt. Django folgt dem aber nicht. Es mag sein das es Aspekte in Django gibt die sich damit Decken, aber das ist teils auch der Fall weil man CoC auch sehr weit fassen kann.