There lies the fallacy. I don't believe there is any 'one best solution' for most given problems, especially in Drupal. No, but what is possible is to come up with an algorithm that leads to a statistically significant improvement on the sustainability and correctness of decisions.
Which is better: a simple solution that gives a few features out of the box, or a highly configurable, extensible solution that requires multiple configurations before it can be used? Well you asked for it: better is an extensible framework which does what 80% of the users want in the minimum/default configuration, and can be expanded to all other use cases by activating extra modules (just like cck, i18n, views, xmlsitemap..). To have different code for simple and complex use cases is what i consider to be the worst case.
It depends on the site being built and on the site builder. In the realm of email subscription modules, for example, the needs of an internal documentation site versus a public news publishing site are very different. So a notification framework clearly needs a lot of clever thinking to come up with a structural design that scales from small and simple to huge and complex. That's why brainstorming on it has to start soon ;)
Likewise, Site builders who are coders are going to be drawn to the module that describes itself this way:
"This is a complete Subscriptions/Notifications Framework aiming at extendability and escalability. It allows any number of plug-ins defining new event types or subscription types or a different user interface."
Site builders who are afraid of PHP will drawn to:
"This module allows users to subscribe to periodic emails which include all new or revised content and/or comments much like the daily news letters sent by some websites"
or, if they already know the drupal lingo and need more power, maybe:
"This module enables users to subscribe to be notified of changes to nodes or taxonomies, such as new comments in specific forums, or additions to some category of blog." So the solution would be two frameworks: "Hi, i am the messaging framework and responsible for handling all communication. You can enable different sub modules for mail, sms, jabber, twitter, smoke signaling according to your needs." and "This module is for handling change notifications of nodes, fields and comments. By itself it does not expose any UI." plus the correspondent modules building on that: "regular notifications UI - user interface to enable intervalled updates for all types of subscriptions" "change notifications UI - notify users when an Drupal object changes" "advanced subscription settings UI - provide UI for more precise control of content subscriptions" (something along these lines, i'm sure many people more experienced with this stuff than me can do better)
Duplicated modules aren't necessarily competing modules. Disagree. I think it's good to have different modules focused on meeting the needs of different audiences. Yes, but the clever way is to make them share code. Just like all the .DLL and .so files on your computer, which are frameworks that provide a broad variety of special functions for applications to use a selected lot of them.
One size does not fit all. No, but reimplementing basic functionality multiple times in incompatible ways is not exactly the clever approach either.
It was suggested that some duplicated modules exist solely to feed developer ego. That's not the most flattering way to put it, but I have noticed that being the maintainer of a module does lead to business inquiries; I'm not keen to give up the publicity. Well the mission of drupal should definitly not to feed module maintainers, but to strive continuously to be the best open source CMS in existence. So this really shouldn't be influencing the decision. Furthermore, my proposal did state that each module collects the credits of its contributor, and i am sure we can find ways to give hard working coders some publicity. Ever read the KDE commit digests? They have some nice statistics at the top (people with most commits/bug fixes/buzz)...
One possible solution to this would be to have project pages list all the committers for a project, and not just the one owner. This would increase the value of collaboration and decrease the hesitation for developers to let a module die in favor or a new, truly better solution. Not invasive enough. In my opinion, bold steps will result in better results here. Trying to _promote_ a certain way of doing things or specific values does not seem to work well enough.
Still voting for 'let the swarm maintain the modules', 'improve code-centric tools and communication' and 'tightly enforce quality standards for the official D7 contrib repository' here. rgds marcel. -- "Obstacles are those frightful things you see when you take your eyes off your goal." -- Henry Ford (1863-1947) Change the world! Vote: http://hfopi.org/vote-future