I do not expect a single @Configuration class accepting several beans with the same name. I guess it should follow the same contract in XML where one could not define in the same XML 2 bean with the same id.
Here is a test demonstrating the behavior. I guess there is no know knowing which bean has been accepted, and this would change from one environment to another.
While this isn't properly documented, it is a supported feature - but not for defining multiple beans of the same name, rather just for providing various factory methods for the same bean. This is then the same algorithm as for choosing the "greediest" constructor or factory method in other configuration scenarios: Depending on the available dependencies, the variant with the largest number of satisfiable dependencies is being picked.
Compare a component class where several constructors are marked with @Autowired; several same-named @Bean methods are an analogous arrangement for factory methods. And with XML, a "factory-method" name will be resolved analogously against all declared methods of that name - the same way that a constructor will be resolved among all candidates for an XML bean definition using autowire="constructor".
Turning this issue into a documentation task, since this needs to be better documented.