I have some comments. I have not had time to look at this as I am finishing up my semester. But yes I think there are five considerations at this time that should be considered on building this.
1. XMF, XMF SHOULD be the basis of any module that can make use of it. This will help make a module 2.6 ready and make any necessary conversions MUCH easier.
2. MVC should be the rule for modules of the future. It does make things much easier to debug and sort of forces use of OOP.
3. We need to make a standardized folder format. In the near future we will be looking at automating installations and it is important to try making the zip folders the same so an installation program knows where to put them.
I suggest the following folders which follow the main xoops installation.
html - should contain all files in the proper folders for installation. An
installation program will just take the folder and copy it into the main
extras - should contain anything extra that isn't normally included in the main
install but may benefit some users.
docs- any help files that may be included. These should be separate and not
installed automatically and should contain any extended help. A future
installer may use this directory to allow someone to install help menus
for a module but for security or to save space may decide not to install.
upgrade - should contain any files or other items needed to upgrade a module
from older versions or perhaps have conversion scripts to allow a new
module to replace an older module.
An install program will likely only use the html and docs folders. The other folders are to help users get their module up and running. May be able to just use the extras folder and not need an upgrade folder.
4. With xoops 2.6 we have a service manager that will allow a module to provide services to other modules. This will become more common place as the manager evolves but in essence a program like xoopspoll that can be used by other programs should have functions setup that are generic and can be accessed on their own by other modules. When building an MVC setup this becomes much easier to do because you can pretty much make the whole "Model" portion into a service manager provider and the "Controller" would make use of it. For xoops 2.5.x you could still make use of such a format but just be aware of the importance to generalize it.
5. Another consideration with an MVC build is that the Model can be built to have objects that are generic and can make service manager service providers easier but can also help clone modules much easier. You should only have to clone the Controller and View portions of the module in this manner. You can leave the original module in place and just copy the view and controller to make a second copy that is totally different than the original. If built with this in mind it can make life much easier in the future.
My semester ends shortly and depending on how next semester lines up and how much I get done during winter break I may be able to help with this. I don't have any pressing projects for xoops other than some service manager stuff I need to finish up for 2.6. I also will only have 2 classes next semester instead of my current 4 which should help dramatically.
Anyhow great start!