First off, let me say, that this module is great, thanks, it has made formatting body and teaser a million times easier.

Contemplate allows inserting a View into the Body or Teaser of a node - this allows for incredible flexibility - albeit a little PHP and Drupal knowledge is helpful/required. I have found that in some cases I want to insert a View (of related nodes - via CCK nodereference) into the Body template of another node, the View I want would be similar to the Teaser List (of the related nodes), but the template for the teaser (of the related nodes) has been defined already for a useful purpose elsewhere (taxonomy/term page) on my site.

Currently, I create a Table View to get the data to show, but that has its limitations of course in terms of presentation.

The solution I envision would include being able to create additional templates (using Contemplate) for a node type and to be able to select the additional template from the View Type list (using Views).

I don't know the Views module very well, but I believe all the functionality exists in Views already so that the only changes would be to the Contemplate module. Views hook functions that may/should be included in the contemplate module:
- contemplate_views_style_plugins
- contemplate_views_validate
- contemplate_views
- contemplate_view_types
- others...

Here are a couple of issues I see, there are no doubt others I haven't thought of.

The Views module in my mind would still do all the querying...
-- every node type should be able to have the additional template/view type
-- a default would need to exist (such as body and teaser have defaults)
-- could use the Teaser of a node type if the additional template hasn't been defined

The new data
1. store it in the current contemplate table
-- add new fields for each additional template needed
-- allow users to create as many as desired - not sure what this would do to the 'flags' concept
-- limit the number of additional templates to some upper maximum - this would be easier on the 'flags'
2. a new table
-- this option would ultimately be more flexible, but would require a lot a reworking of the module
-- not sure this option is worth all the extra work

Naming the additional templates/view types
-- depends on where data is stored
-- users define the names - adds complexity, but may improve usability
-- module defines the names - easier to code, easier to explain

UI
1. extend existing template edit page with fields for the additional templates
-- could become long form especially if node object is loaded for each
2. tabbed form
-- keep the existing form, add 'additional templates' tab or 'advanced' tab to get to the UI for the additional templates

Reset
-- reset all?
-- add buttons to reset specific templates