Okay it's time for me to chime in here again...
I've been developing modules and assisting with the core now for a long time, and my opinions have changed over the years, as well a few CMSMS facts have changed.
Module Developer Skill
Just as we assume that the CMSMS user is a professional user, and don't document things that aren't related to CMSMS, we should assume that the module developer is not a 'weekend php coder, weekday auto mechanic'. Therefore we should not make attempts to document things like 'how to use svn' or 'how to code php' or any other such thing that is not specifically related to CMSMS.
Added: Topics like 'how do I do a checkout in svn' etc, can be answered by google. All we need to do is make it easy for people to find the CMSMS specific information.
PHP5
This is a given now, and a standard... we no longer support php4 and I have not been supporting it for even longer than that in my modules. There is a class autoloader already in the core and in CGExtensions to make loading classes automatic, and therefore allows you to split up your code into separate classes much easier.
However, just due to the 'if its not broke why fix it' mentality, there's no reason to go whole heartedly through each module and change it to work only with php5. As time goes by more 'private and protected' keywords will be introduced (I wish php had friend relationships). But in new code, I would suggest using them liberally. I think member variables for a class should ALWAYS be private.
Naming / Coding Standards
I support the idea of an interface class for assisting module develoeprs, however I am not sure if it's going to be as simple as that... as we currently only have one base class (CmsModule) for developing from, and most of the methods there are stubbed so that module developers don't have to override each one unless necessary. There are only a few methods that must be overridden.
I also will not support any strict naming (or for that matter coding styles) rules within CMSMS. Each developer has their own style (and that style changes over time depending upon their needs and experience). As well, even the gnu coding standard has changed over time, and I personally don't like it. As the primary developer on my modules they are written so that I can read them easily.
When I write a module I (try to) write it so that I can maintain it, that includes code documentation. If the formatting and documentation is a benefit or a hindrance to other (potential) developers, that's an afterthought.
If another developer is reading/editing the code they are assumed to be proficient enough to be able to read that code independent of how it is formatted or how the functions are named. I've been working with code for ~20 years now, and have had this 'problem' throughout that time (ever tried to debug integer overflow problems in some electrical engineers hacked together F77 code... I still have nightmares). The best solution is to learn how to read the code. Yes it may be more convenient (for some) to have a strict coding style that they can learn and and then it is quicker to read and understand the code, but it is only a minor aide.
Added note: all attempts should be made when working with somebody elses code to match their coding standards. Don't re-format the whole file for a 3 line patch and expect us to be happy about what you did.
Database Independance
I am of mixed opinions on this. Although in principle I like the idea of being able to work with umpteen different databases (sqlite would be my one of choice), I think now that that should be left to the choice of the module developer, based on his needs. With over 80 modules/plugins that I maintain at this point, I have had only little requests or complaints about compatibility with postgres. Also doing some research have found that less than 10% of websites out there are using postgres, which means that it is potentially alot of effort for a small portion of the market to support that database. So therefore, let the module developer decide based on his need. MySQL support though would be required.
Query Efficiency
This is one of those things where we learn as we go. I regularly go through and improve the efficiency of my queries (as I introduce new features) or add indexes to aid in the queries, etc. and this is because well... when I started with CMSMS I was a relational database noob. Now I know some different things, others will go through the same exercise. Not much we can do about this except for providing feedback to the module developers using the standard mechanisms.
CMSMS Permissions
I'm of mixed opinions about this too. The package is named 'CMS MADE SIMPLE'. to provide a simple mechanism for 80% of the websites we find we produce. Why introduce a complex hierarchical permissions model just to solve the case for 20% (or less) of the sites we need to implement. It doesn't make much sense. There is a flat list of permissions, and each group can have different permissions, and a user can belong to multiple groups... that's about as flexible as we need.
Now we should make an effort (for security purposes) to call CheckPermission() with the appropriate arguments at the top of our admin actions, and at any place where options can be displayed differently for users with different permissions.
Documentation / Skeleton Module
I don't think it's a bad idea to use the Skeleton module as our primary form of communication with the module developer, as a tutorial of sorts (which is what it is). And yes this could be brought into the pervue of the core developers (I don't think that _SjG_ would have a problem with that).
However, when considering documentation also consider that for developer documentation we are aiming at the experienced programmer. Therefore we need a well documented API (we took care of that in 1.
and we need some good examples/tutorials. The developer can then look at those examples/tutorials to figure out how to do things. This largely works... just the skeleton module needs a bit of updating for 1.8 and for php5. There are also alot of other examples out there in the various modules... somebody just needs to ask where they are.
Conclusion:
In conclusion I don't want to put too many 'rules' as to how developers should format their code, name their functions, etc. However we do need to make sure our examples are kept up to date, and that we provide a decent support mechanism for the well asked question from developers on the forum.
Addendum:
There has been debate over time as to whether modules should include stylesheets for their sample templates. I say that they should not. The templates we distribute with our modules are meant to be examples, and a 'getting started' guide for designers. There is no way we can know how somebody will attempt to use the module, or what color scheme, styles, or conventions they are applying. They are free to change any div's or id's in the templates, add new ones, re-arrange the templates at will. Providing stylesheets with the modules is IMnsHO just an added complication to the professional web developer. However, I in no way want to make this a 'rule'. Just my recommendation.