Ok… Je me lance avec mes réflexion actuel sur l’API autoriser. D’abord avec mes constats au sujet de l’API puis mes réflexions…
Comme j’arrive dans le sujet, il est possible qu’il y a des éléments la-dedans qui auront déjà été discuté par ceux qui discute sur cette liste depuis longtemps, soyez indulgent de ce côté ! 
Il est également possible que mes constats soient faux, n’hésitez pas a me faire par de fonctionnalités que j’aurais manqué au travers de mes différentes lectures sur le sujet…
Et finalement, si jamais les besoins que moi je ressens pour faire évoluer l’API autoriser de spip sort des besoin de spip lui-même et sont des besoins qui sont vraiment plus spécifique à mes besoins, n’hésitez pas à me le dire, et je me ferais un plugin pour surcharger cela et utilisera bien celui qui veut a partir de là !
Mes constats sur l’API Autoriser actuellement…
Dans le contexte ou on gère 3 statut de base (0minirezo, 1comite, 6forum) et que tout nouveau statut d’auteur est de base considéré comme un statut visiteur, l’API actuel fonctionne relativement bien… Mais, comme je l’ai dis précédemment, dans un contexte ou je me sers de SPIP pour gérer des intranet, ces 3 statuts sont nettement insuffisant et ne permet pas d’avoir beaucoup de souplesse à moins de se mettre a écrire pleins de fonction et/ou de surcharger des fonctions actuel…. Il est d’ailleurs très difficile avec son concept actuel de créer une interface dans l’espace privé pour pouvoir créer de nouveau statut et d'assigner a ce statut des droits spécifique, les droits n’existant pas autrement que par création de fonctions…
Si je prends exemple au niveau de mes intranet, si dans mon intranet, j’ai des objet factures, clients, commandes, formulaires, etc, etc, et que je souhaite déléguer a une personne la gestion des utilisateurs pour qu’il puisse gérer les droits d’accès pour créer un droit « comptabilité » et assigner des droits sur les objet factures sans que cette personne ai accès au reste, c’est impossible de créer ce droit « comptabilité » sans passer par de la programmation…
Donc pour pouvoir arriver a créer des statut d’auteur « personnalisé » il faut commencer par être en mesure d’avoir une liste des droits disponible pour chaque objet. La première idée qui me vient donc en tête, c’est d’ajouter cela lors de la déclaration des objets par le pipeline declarer_tables_objets_sql …
Si dans cette table on ajout a notre objet quelque chose de ce genre :
$tables[‘spip_mon_objet_quelconque’]
… blabla définition de la table …
… blabla les statut pour l’objet …
… blabla autres …
‘dtoits_autorisations’ => array(
‘creer’ => array(
‘texte_de_langue’ => ‘fichier de langue:string’,
‘restreindre_rubrique’ => ‘oui ou non’ /* Pour décider si pour ce droit, on peut choisir un secteur ou si c’est le droit point final */
‘autres_options_qui_pourait_etre_interessante’ => ‘…'
),
‘modifier’ => array(
…..
),
etc….
);
En faisant cela, il devient possible d’écrire une fonction du genre :
liste_droit_objet($objet)
et ainsi récupérer une liste de droits disponible pour un objet en particulier…
Cela laisse même la possibilité pour un autre plugin qui aurait besoin d’ajouter un droit sur un objet existant pour xyz raison, d’aller l’ajouter en passant par le pipeline déclarer_tables_objets_sql …
Dans la fonction liste_droit_objet, on pourrait introduire certains droits de base ou exceptionnel comme webmestre ou des éléments de ce genre…
Ensuite pour compléter cette gestion de droits, j’ajouterait une table, par exemple spip_statut_auteur … qui se définirait a peu près comme ceci :
id_statut
Titre
libelle (le nom du droit, mais qui sera associé au statut de l’auteur… A moins qu’a partir de là, les droits des auteurs passent par une table de liens… Ça permettrait même qu’un utilisateur ai plus d’un droit… Mais au niveau de la structure de spip, l’utilisation du champ statut ne doit pas être si simple a remplacer… )
liste_des_droits qui serait un peu comme les meta de SPIP, un serialize (c’est comme ça qu’on dit ?? 
) des droits par objet que ce nouveau statut d’auteur peut faire …
En gros, la base de mon idée est là… plutôt que d’avoir un paquet de fonction éparpillé un peu partout pour gérer les droits sur les objets spip, on pourrait avoir une seule fonction qui vérifie si la personne a un droit en fonction de son (ou ses) statut, et l’ensemble des droits possible pourrait être assigné a des nouveau statuts… On peut inclure les statuts de base (0minirezo, 1comite, 6forum)de spip actuel déjà dans la table par défaut, et après, on peut créer autant de statut que l’on veut en décidant des droits assigné a chaque statut…
Si cette idée allume quelque choses et est d’intérêt pour le coeur de SPIP, je suis partant pour écrire le code qui va avec, mais j’aimerais bien avoir de l’aide pour choisir les bons termes, les bon nom de fonction, etc, afin que celui puisse être éventuellement intégré au coeur de SPIP…
Si cette approche n’est pas intéressante pour le Core, alors je le ferais comme plugin, mais s’il y en as qui ont des suggestions pour la nomenclature, je suis preneur ! 
Ce qu'ils attendent, c'est un niveau de réponse et de réflexion qui les fasse avancer (avec bonheur).