So yet another rant bemoaning Drupal's internals wanting a more elegantly decoupled internal architecture. Decoupling Drupal's internals in the ways suggested would be no easy feat and a fool's errand to even try. What's the objective? "So we can have more reasonable unit tests." That's sort of hilarious. Drupal is not exactly a test-driven culture. "So we can reuse these components in other frameworks." Seriously? You want to reuse Drupal's theme registry some place else, like wanting your bike, your car, and your golf cart to have the same size wheels because that'd be more convenient for you?
Drupal project leads need to avoid getting distracted by this noise. Drupal is not and should not try to be an architectural masterpiece because the typical Drupal adopter has no idea what a unit test is anyway. Addressing these complaints will add no value for the typical Drupal user. Drupal is utilitarian. Drupal fulfills the need to slap together a web site quick and make it pretty, and you don't want to know what's going on underneath. If you want architecture and unit tests then there are plenty of other frameworks out there to consider instead.
Perhaps you should listen to the core developers who started this debate, when they explain what's burning them out? For better or worse, architectural decisions in Drupal's past have resulted in very large workload for a relatively small number of developers, and great pressure from others in the community to "Keep the system running" in the face of numerous feature requests and so on.
There's a difference between "Let's turn Drupal into an architectural masterpiece" and "Let's refactor some of this stuff to make it more manageable." Drupal has long had a culture that devalues planning and deliberation while glorifying the "firehose of code." Attempts to iron out the best path for a complex change can only go on for a few days before they're shut down with cries of "Talk is silver, code is gold!"
Obviously, the other extreme -- endless unresolved attempts to come up with the "perfect master plan" -- is just as unproductive. But there's a healthy middle ground that needs to be maintained for a project of this size to avoid crumpling under its own weight.
To get a better context read the discussion threads linked from this article, which inevitably lead back to the "small core" discussions. The Drupal project has been increasingly distracted by debating fantastic hopes and dreams, and there's a definite sense of immediate issues not being addressed because everyone is waiting for the great architecture debate to be settled first, which it never will.
> Drupal fulfills the need to slap together a web site quick and make it pretty...
You had me until that. Usually you can tell a site is Drupal by how ugly it is and how awful the code is. Also, putting together a site in drupal is far from quick, unless you've been working with drupal for years.
Drupal project leads need to avoid getting distracted by this noise. Drupal is not and should not try to be an architectural masterpiece because the typical Drupal adopter has no idea what a unit test is anyway. Addressing these complaints will add no value for the typical Drupal user. Drupal is utilitarian. Drupal fulfills the need to slap together a web site quick and make it pretty, and you don't want to know what's going on underneath. If you want architecture and unit tests then there are plenty of other frameworks out there to consider instead.