Quando faccio il provisioning delle site column, dei content type, delle list definition e delle liste utili a specifiche funzionalità della mia applicazione SharePoint, sono solito dividere per bene i vari componenti della soluzione in differenti feature.

Solitamente cerco di seguire la regola di avere una feature a livello di site collection (scope=site) che contiene le site column, i content type e le list definition che possono servire a tutta la site collection e avere una o più feature a livello di singolo sito (scope=web) con le varie list instance. Questo perché preferisco avere un unico punto in cui saranno presenti tutte le definizioni di liste (per poter essere poi utilizzate in tutti i sotto siti) e creare poi le liste vere e proprie solamente all'interno dei siti in cui mi servono.
Giusto per capirci, una struttura di questo tipo:

La struttura della mia soluzione SharePoint

Ecco, provate ora a creare un content type e una list definition (con il flag sull'opzione "Add a list instance for this list definition").

Creazione di una nuova list definition

In automatico Visual Studio inserisce questi oggetti nella prima feature con scope=web che trova. Che vabbè, ci può stare come comportamento, anche se comunque mi sarebbe piaciuto tanto che mi facesse scegliere in quale feature metterle (questo sarebbe un grandissimo aiuto per soluzioni di grosse dimensioni con la presenza di tante feature).
A me però questa scelta non va bene in quanto, seguendo la mia regola di base, voglio spostare content type e list definition a livello di site collection e avere poi la possibilità di creare la relativa lista in più siti (quindi attraverso una feature con scope=web).
Spostando site column, content type e list definition nella seconda feature, arrivo ad una situazione di questo tipo:

Feature con scope=site
Feature con scope=site

Feature con scope=web
Featue con scope=web

Non se che ne pensate voi, ma a me sembra una buona configurazione questa.
Ripeto: io utilizzo questa configurazione per specifiche componenti della mia soluzione, non la applico per tutti i componenti di provisioning di tutta l'applicazione, in quanto è sempre bene dividere le varie funzionalità in specifiche feature, questo per facilitarsi la vita in fase di deployment o di aggiornamento. 

Se però provo a fare il deploy della soluzione, Visual Studio interrompe l’attivazione della feature con scope=web e mi presenta il seguente errore: 

Error occurred in deployment step 'Activate Features': Cannot complete this action.

Errore cannot complete this action

In generale l'errore "Cannot complete this action" è sempre legato alla parte di provisioning delle vostre applicazioni. Anche in questo caso infatti, la parte della nostra implementazione che non va giù a SharePoint è la list instance.
Per organizzare gli oggetti tra le due feature secondo la mia logica, ho spostato la list instance all’interno di una feature in cui non è più presente la list definition che deve essere utilizzata per creare tale lista. In questa situazione SharePoint non sa dove prendere la list definition per creare la nostra lista, blocca l'operazione e torna quell'errore. 

Per risolvere ci basta specificare l'ID della feature che contiene la list definition da utilizzare per creare la list instance, utilizzando l’attributo FeatureId.

Utilizzo del campo FeatureId all'interno della list instance

Per recuperare questo identificativo, che Visual Studio genera per noi ogni volta che aggiungiamo una nuova feature alla nostra soluzione, basta aprire la feature interessata, fare click sul pulsante "Manifest" (in basso nella schermata) e selezionare il valore dell'attributo Id.

Come recuperare l'ID di una feature tramite il designer di Visual Studio 
In questo modo avete specificato a SharePoint dove sta la list definition da utilizzare per creare la vostra lista e vedrete che il deploy andrà a buon fine. 
Spero vi sia utile.

Vi lascio qui anche i sorgenti d'esempio: