Thanks for clearing that up. Your instinct is probably right, in that it would be a surprising effect to most users to ignore the entire resource location if one (or more) placeholders did not resolve. While it's conceivable to add an attribute to the annotation that makes this configurable, it's probably the wrong path to head down as well. This sort of special case really calls out for full programmatic control.
As you're probably aware, you can manipulate property sources in any way you please by working against the ConfigurableEnvironment API off of your enclosing ApplicationContext. If you're within a webapp, use an ApplicationContextInitializer to do this.
Additionally, if certain among these property sources are indeed dependent on the runtime environment as your naming above suggests, you could possibly get the job done through the use of @Profile and (possibly nested) @Configuration classes. i.e. a @Configuration marked with @Profile("x") as well as @PropertySource("x.properties"). Only if profile 'x' is active will that @Configuration class be processed, including any @PropertySource annotation it may declare.
Thanks again for the feedback. Keep it coming!