Working with composite views is a common problem a lot of framework developers run into. Applying the DRY principal to view logic and trying to maintain the KISS principal can be a huge pain. The nature of markup tends to be very repetitive. Not only is it competitive often times you have several types of markup within an application (XML, XHTML, WAP). Creating markup components and dynamically injecting them into a aggregate to be rendered to the user generally meas it's a easier to manage the individual components but in many cases impossible for non developers to modify the look and feel of an application without developer interaction. This kind of kills one of the goals separations is after.

One thing I currently utilize is a series of libraries I created to compile composite views. I have a library that will recursively inject rendered view content into a single view script which can then be edited by a designer or loaded with a controller. This alleviates a few steps in the rendering process as well. The compiled view can also be decompiled to re-organize or re-factor shared components.

Ultimately whether you use some kind of view compilation or a lot of redundant view code, composite views are still the way to go for now.