El desafío de utilizar un enfoque de archivo de configuración es que tendría que modificar constantemente el archivo. SSIS no volvería a cargar el archivo de configuración después de que se inicie, por lo que es posible que tenga trabajos de 8:05 y 8:35 PM que intercambien archivos de configuración, pero eso se ensuciará y se romperá en algún momento.
Me gustaría manejar esta situación con las variables de línea de comando (/set option in dtexec). Si estuviera ejecutando el paquete desde la línea de comando, se parecería a dtexec.exe /file MyPackage.dtsx Incluso si está usando el Agente de 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 trabajos programados 2 veces al día). AgentMyPackage2011 tiene un paso de trabajo de SSIS que se traduce en
dtexec /file MyPackage.dtsx /Set \Package.Variables[User::Year].Properties[Value];\"2011\"
y AgentMyPackage2012 tiene un paso de trabajo de SSIS que se traduce en
dtexec /file MyPackage.dtsx /Set \Package.Variables[User::Year].Properties[Value];\"2012\"
A través de la GUI, se parecería a algo como 
No hay ninguna interfaz gráfica de usuario o el selector de la propiedad que desea configurar. Sin embargo, puesto que ya ha creado un archivo .dtsConfig para su paquete, abrir 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 el camino a la "cosa" que está tratando de configurar, de modo ponlo en tu programa de llamadas y luego apaga la porción del año de la configuración del paquete.
Finalmente, un enlace a SSIS Configuration Precedence ya que existen diferencias en el modelo 2005 vs 2008. Veo que indicó 2008 en su boleto, pero para futuros lectores, si usa tanto/SET como una fuente de configuración (servidor xml, sql, registro, variable de entorno), el orden de las operaciones varía según las versiones.