El desafío con el uso de un enfoque de archivo de configuración es que necesitaría modificar constantemente el archivo. SSIS no volvería a cargar el archivo de configuración después de que se inicie, por lo que posiblemente podría tener trabajos a las 8:05 y 8:35 p. m. que intercambian archivos de configuración, pero eso se complicará y se romperá en algún momento.
Manejaría esta situación con variables de línea de comandos (/set option in dtexec ). Si estuviera ejecutando el paquete desde la línea de comandos, se vería algo así como dtexec.exe /file MyPackage.dtsx Incluso si está utilizando el Agente SQL, detrás de escena está construyendo esos argumentos de línea de comando.
Este enfoque supone que crea dos trabajos diferentes (frente a 1 trabajo programado 2 veces al día). AgentMyPackage2011 tiene un paso de trabajo de SSIS que da como resultado
dtexec /file MyPackage.dtsx /Set \Package.Variables[User::Year].Properties[Value];\"2011\"
y AgentMyPackage2012 tiene un paso de trabajo de SSIS que da como resultado
dtexec /file MyPackage.dtsx /Set \Package.Variables[User::Year].Properties[Value];\"2012\"
A través de la GUI, se vería algo así como 
No hay GUI ni selector para la propiedad que desea configurar. Sin embargo, dado que ya ha creado un archivo .dtsConfig para su paquete, abra ese archivo y busque una sección como
<Configuration ConfiguredType="Property" Path="\Package.Variables[User::Year].Properties[Value]" ValueType="Int32">
<ConfiguredValue>2009</ConfiguredValue>
El archivo ya tiene la ruta a la "cosa" que está intentando configurar, así que introdúzcalo en su programa de llamada y luego desactive la parte del año de la configuración del paquete.
Finalmente, un enlace a Precedencia de configuración de SSIS ya que hay diferencias en el modelo 2005 vs 2008. Veo que indicó 2008 en su ticket, pero para futuros lectores, si está usando /SET y una fuente de configuración (xml, servidor sql, registro, variable de entorno), el orden de las operaciones varía entre versiones.
