We're developing a managed package for delivery through the AppExchange.  Our custom business objects will be extended by our customers, and we're using custom VisualForce pages to present and edit these objects for a variety reasons.  This scenario is obivously one of the main reasons for the existence of field sets, allowing us to create the view in way that's flexible enough to adapt to a customized model in each deployment.  In principle this all sounds great, but in practice we're having a few issues.  I'm hoping someone here can provide some guidance on either a way to solve these issues with VisualForce and/or field sets or a way to work around them without having to create a big framework that we'll then own.

The first issue is that currently the field set metadata doesn't seem to be included in the objects downloaded through the Force.com IDE, though it does look like it's now included when using the ant targets.  My fear is that developers using the Force.com IDE will lose the field sets when they check their other changes into SCM if they're not incredibly careful on every check-in.  Does anyone know if the Force.com IDE is going to be updated soon to address this disparity, or is there a better way to manage this, perhaps by having the Force.com IDE not include the object metadata in its package?

The second issue, and this is the more serious one, is that while most of our fields can use the standard apex:outputField and apex:inputField components that are metadata-aware, we have to use custom components with some fields.  Since field sets are effectively just a named, ordered list of fields from an object, what's the best way to associate custom components as the default way to display and/or edit a field when it's presented?  I imagine that dynamic VisualForce components might be (part of) the answer to this question, but they're not generally available and are discouraged from use in production or managed packages.  I've considered creating a custom object that acts as auxiliary metadata for field sets, in particular a custom component name, but because there's really no way to do something like (pseudocode):

<apex:repeat value={!$ObjectType.MyObject.FieldSets.HeaderFormFields}" var="field">
    <apex:outputField rendered="{!hasCustomComponent(field)}" value="{!field}"/>
    <!-- No way to render a custom Apex component by name dynamically (without dynamic VisualForce components?) -->
    <apex:renderComponent rendered="{!hasCustomComponent(field)}" name="{!getCustomComponent(field)}" value="{!field}"/>
</apex:repeat>

An example of a custom component's body might be something as simple as:

<apex:pageBlockSectionItem>
    <apex:outputLabel value="Select Value" for="someList"/>
    <apex:selectList value="{!CustomObject__c.SomeValue__c}" size="1" id="someList">
        <apex:selectOptions value="{!someListValues}"/>
    </apex:selectList>
</apex:pageBlockSectionItem>?

or might be as sophisticated as a jQuery in-place editable grid.

Anyone have any thoughts here?  Are we basically stuck until/unless we use dynamic VisualForce components?  If that's the case, has anyone producing a managed package done so successfully?  How did you coordinate that with your customers?

Thanks in advance for all insights!