Module weights sometimes come into play when you’re trying to override certain aspects of the core or other modules. If you look in the Drupal database’s system table you’ll notice a field called weight - this is what determines the order in which all of the installed modules’ hooks will get called during a page request.
If you haven’t listened to Lullabot Podcast No. 75 yet, go check it out. It’s an excellent discussion around the problem of how to distribute the cool and interesting things you’ve built with Drupal in a reusable way, or in such a way that those features can be bolted on to an existing web site.
I am not really involved at all with the day to day development of Drupal or debates over its future, but from some of the issues discussed on the podcast and some of the debates over UI I heard at Drupalcon DC, it seems like there’s a fundamential tension growing over whether Drupal is the web application itself, or just a set of APIs upon which you can build great web applications (and which happens to have a built-in CMS that you can’t turn off.)
In terms of reusable features, the current response you get when asking “Hey, is there a module to do X in Drupal?” is usually along the lines of, “Sure. You just have to install the Frobnosticator module, then create a Foo Profile with the Potrezebie module and configure a workflow so that the Fonebone action gets triggered by foo_nodeapi blah blah blah. It’s easy!”
The problem is that it’s not really easy if you’re not familiar with any of the modules involved in the recipe. Often times it seems like you spend so much time on the configuration and interaction of modules to achieve something only partially resembling the functionality you had in mind that you might have been better off writing a module from scratch that does exactly what you want, without the clunky overhead of half a dozen modules all sort of working together.
I’ll be following Features/Install Profiles/Distributions discussions with interest.