I can not agree more. As one of the guys who introduce quite big changes often, I can only think of so many edge cases. I already posted that it's time to look at those parts of the menu which handles the 'i browse to this url and i get this page' case and I would be delighted if people would try to port their module over to that. Another prime example are forms. There are just too many combinations to be able to test them all. It already happened that some need could only be fulfilled half a year later because we have not had input. So, port your module, speak up and the next Drupal will fit better *your* needs. It's again 'scratch your itch'. Regards, Karoly Negyesi
bottom line on this point: if you're up to the task, trying to keep your module's version of HEAD in sync with the (ever-changing) version of the API in core's HEAD is a worthy, noble goal, and it should be encouraged as much as possible. if they keep up with the changes, contrib developers:
a) will be more familiar with the new changes to the API taking place, and in general, be more knowledgeable about the core API itself
b) will have more chances to find/correct problems with the API changes while there's still room to move
c) won't have to do all the porting at once
d) will help add momentum to the new version of core, since as soon as the first RC ships, there will already be a set of modules compatible with it